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The  purposes  of  this  study  were  to  develop  a  model  for  an  in-flight  system  status  monitor 
that  could  be  applied  to  the  National  Aerospace  Plane,  and  to  implement  a  computer  program  to 


demonstrate  the  feasibility  of  that  model. 

The  system  status  monitor  model  which  I  developed  features  dual  hierarchical  structures,  one 
for  the  aircraft  components  and  functions  to  be  diagnosed,  and  another  for  the  diagnostic  functions 
to  be  performed.  The  aircraft  knowledge  base  included  elements  from  each  level  of  the  aircraft 
hierarchy,  from  primitive  components  through  the  overall  mission.  The  diagnosis  hierarchy  which 
was  implemented  only  included  diagnosis  and  remediation.  The  addition  of  the  other  diagnostic 
functions  to  the  demonstration  program  would  be  a  valuable  project  for  future  students. 

I  wish  to  thank  several  people  for  helping  with  this  thesis  efTort.  My  thesis  advisor,  LtCol 
Charlie  Bisbee,  invariably  offered  suitably  probing  questions  and  subtle  guidance.  Ms  Kathy  Abbott 
provided  me  with  a  copy  of  her  Faultfinder  software  and  considerable  insight  into  its  theory  and 
operation.  Capt  Carl  Lizza  steered  me  in  Kathy  Abbott's  direction,  thus  making  implementation  of 
my  ideas  much  easier.  Mr  Mike  Snead  offered  enthusiasm  and  support  when  others  were  skeptical. 
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Abstract 

The  purposes  of  this  study  were  to  develop  a  model  for  an  in-flight  diagnostic  system  that 
could  be  applied  to  the  National  Aerospace  Plane,  and  to  implement  a  computer  program  to 
demonstrate  the  feasibility  of  that  model  as  a  basis  for  a  system  status  monitor. 

The  diagnostic  system  model  which  was  developed  features  a  double  hierarchy  structure,  one 
for  the  aircraft  functions  to  be  diagnosed,  and  another  for  the  diagnostic  functions  to  be  performed. 
The  hierarchical  nature  of  both  the  system  knowledge  and  the  functions  that  use  the  knowledge 
allow  decomposition  of  the  diagnostic  task  into  relatively  independent  and  manageable  parts. 

The  demonstration  program  which  was  developed  includes  a  subset  of  the  diagnostic  system 
model.  This  program  was  implemented  in  Zetalisp  on  a  Symbolics  3600  computer.  It  will  simulate 
monitoring  the  dynamic  performance  parameters  of  an  aircraft’s  subsystems,  report  any  readings 
that  fall  outside  of  predetermined  limits,  reason  about  components  responsible  for  the  fault,  display 
to  the  aircrew  the  other  aircraft  functions  which  may  be  affected  by  the  component  fault,  and 
recommend  actions  that  may  remedy  the  fault  situation. 

The  demonstration  program  clearly  shows  the  validity  of  the  diagnostic  system  model  and 
highlights  the  importance  of  the  causal  and  functional  relationship  techniques  used  to  represent 
knowledge  of  the  aircraft  and  its  environment.  The  program  demonstrates  how  the  diagnostic 
system  can  supply  relevant  system  status  information  to  the  aircrew.  The  report  concludes  with 
several  recommendations  for  enhancements  to  the  demonstration  program. 


A  System  Status  Monitor  for  the  National  Aerospace  Plane 

I.  Introduction 

A  general  and  continuing  trend  in  aerospace  vehicles  is  their  increasing  complexity.  These 
vehicles  are  becoming  larger,  are  operating  at  higher  altitudes  and  greater  speeds,  and  are  expected 
to  perform  with  greater  reliability.  Despite  this  rapid  increase  in  the  complexity  of  aircraft,  the 
crewmembers  who  operate  them  must  use  human  decision-making  capabilities  which  have  remained 
relatively  constant  over  the  years. 

Perhaps  the  extreme  example  of  a  complex  aerospace  vehicle  is  the  proposed  National  Aero¬ 
space  Plane  (N'ASP)  The  N'ASP  will  be  able  to  take  off  from  a  conventional  runway,  and  either 
cruise  at  hypersonic  speeds  in  the  upper  atmosphere,  or  accelerate  to  speeds  sufficient  to  attain 
low  earth  orbit.  The  prototype  NASP  aircraft,  designated  the  X-30,  will  demonstrate  this  mission 
capability  with  as  few  as  two  or  three  crewmembers  [22].  Such  a  complex  vehicle,  performing  such 
a  demanding  mission  with  a  minimum  crew,  will  require  extremely  well-designed  aids  to  help  the 
aircrew  maintain  full  control  of  the  aircraft.  The  aircrew  aids  will  be  especially  important  if  and 
when  abnormal  conditions  arise  in-flight. 

II  Problem 

The  problem  investigated  in  this  study  is  to  develop  and  demonst  rate  a  strategy  for  an  in-flight 
system  status  monitor  for  the  National  Aerospace  Plane.  This  monitor  should  be  able  to  assess  tiie 
health  and  status  of  various  aircraft  systems,  recognize  deviations  from  normal  operation,  diagnose 
the  causes  of  the  faults,  and  report  the  possible  consequences  of  the  faults  to  the  aircrew  Because 
of  the  complexity  of  the  NASP,  the  system  status  monitor  strategy  must  account  for  the  intricate 
interaction  of  aircraft  systems.  The  system  status  monitor  should  help  increase  the  decision-making 
capabilities  <>f  the  aircrew  so  they  can  keep  pace  with  increasing  aircraft  complexity. 


1.2  Scope 


While  the  system  status  monitor  developed  in  this  report  can,  in  theory,  include  every  aircraft 
subsystem  and  component,  the  demonstration  program  only  includes  five  major  aircraft  systems; 
propulsion,  fuel,  hydraulics,  flight  controls,  and  thermal  protection.  The  demonstration  program 
also  fully  implements  only  the  diagnosis  and  remediation  aspects  of  the  full  diagnostic  process.  This 
set  of  aircraft  systems  was  considered  sufficient  to  investigate  the  interactions  between  and  within 
systems.  Also,  the  two  diagnostic  functions  were  enough  to  show  the  feasibility  of  using  artificial 
intelligence  techniques  to  perform  system  status  monitoring. 


1.3  Assumptions 

In  this  study,  all  discussions  of  the  diagnostic  process  will  assume  that  single  faults  cause  all 
observed  fault  symptoms  at  any  single  point  in  time. 

Since  the  National  Aerospace  Plane  is  still  in  the  planning  stages,  all  references  in  this  study 
to  its  missions,  capabilities,  and  configuration  are  based  on  conjecture.  One  example  of  this  is  the 
model  of  the  NASP  propulsion  system  used  in  this  study.  While  the  actual  NASP  may  use  any  one 
of  a  variety  of  propulsion  plants,  the  one  modeled  here  is  the  airturbo  ramjet  (ATR)  [21].  With  a 
maximum  speed  capability  of  about  Mach  6,  the  ATR  would  not  be  sufficient  by  itself  to  propel  t  he 
NASP  to  orbital  speeds,  but  it  could  be  used  in  conjunction  with  other  propulsion  technologies. 

While  the  actual  NASP  will  certainly  require  more,  only  five  aircraft  systems  are  modeled 
here.  They  are  propulsion,  fuel,  hydraulics,  flight  controls,  and  thermal  protection.  These  were 
considered  the  most  important,  and  should  be  sufficient  to  illustrate  the  concepts  of  NASP  system 
status  monitoring 

These  assumptions  had  some  effect  on  the  quality  and  completeness  of  the  diagnostic  knowl¬ 
edge  base.  The  causal  or  functional  knowledge,  which  is  based  on  the  defined  structure  of  the 
aircraft,  was  not  greatly  .affected  because  it  corresponded  to  the  aircraft  as  it  was  artificially  de- 
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fined  for  this  study.  However,  the  compiled  or  experiential  knowledge  was  very  sparse  because  there 
was  no  actual  experience  with  this  aircraft  to  draw  upon.  The  final  results  of  the  study  are  still 
valid  because  the  representative  cases  used  to  test  the  demonstration  program  show  the  effective 
use  of  both  types  of  knowledge. 


1.4  General  Approach 

This  study  was  undertaken  as  a  series  of  steps  leading  from  research  into  the  nature  of  the 
NASP  mission  and  the  diagnostic  process  to  the  development  and  testing  of  a  computer  program 
which  demonstrated  the  feasibility  of  the  diagnostic  model.  The  research  into  the  nature  of  diag¬ 
nosis  showed  that  the  process  of  diagnosis  actually  is  at  least  a  two-step  activity  involving  system 
monitoring  and  then  fault  isolation.  To  become  more  useful  for  aircraft  system  status  monitoring, 
diagnosis  can  be  extended  to  a  five-step  process,  as  will  be  discussed  in  Chapter  III. 

To  implement  the  multi-step  diagnosis  model,  different  artificial  intelligence  problem-solving 
techniques  were  investigated.  The  most  promising  found  was  the  blackboard  problem-solving  model. 
A  blackboard  is  a  structured,  global  database  which  serves  as  a  central  repository  of  information  to 
be  accessed  by  separate  and  independent  expert  systems  [8,  3].  Blackboards  and  their  application 
to  the  NASP  system  status  monitoring  task  will  be  discussed  at  length  in  Chapter  IV. 

The  research  next  turned  to  a  search  for  a  suitable  expert  system  shell  that  could  support 
the  blackboard  model.  Several  general  purpose  shells  were  found,  but  all  were  either  themselves 
in  development  or  were  not  readily  available  at  this  Institute.  A  special  purpose  aircraft  diagnosis 
system  was  found  in  development  in  the  Vehicle  Operations  Branch  of  the  NASA  Langley  Research 
Center.  This  system,  called  Faultfinder,  uses  a  blackboard  data  structure  to  organize  interaction 
between  the  different  parts  of  the  program.  Faultfinder  became  the  basis  for  the  NASP  system 
status  monitor  reported  here. 

Prototype  development  involved  a  number  of  modifications  and  extensions  to  the  Faultfinder 


system.  Faultfinder's  target  domain  is  commercial  transport  aircraft,  and  its  knowledge  base  and 
user  interface  were  developed  for  that  domain  [19,  l].  The  first  task  was  to  adapt  Faultfinder  to 
the  NASP  domain.  Next,  Faultfinder  was  modified  to  perform  diagnosis  on  multiple  levels  of  the 
aircraft  functional  hierarchy.  Finally,  a  remediation  function  was  added  to  propose  actions  that 
could  be  taken  by  the  aircrew  given  a  certain  fault  diagnosis. 

Finally,  the  modified  Faultfinder  system  was  tested  with  several  sets  of  theoretical  fault  symp¬ 
toms.  The  system  performed  adequately  in  most  cases,  but  a  number  of  areas  needing  improvement 
were  discovered.  Recommendations  are  made  in  Chapter  VI  as  to  the  implementation  of  these  im¬ 
provements. 

I. 5  Sequence  of  Presentation 

Analysis  of  the  problem  of  system  status  monitoring  for  the  NASP  is  presented  in  Chapter 

II.  This  includes  definition  of  the  problem,  and  a  review  of  the  literature  related  to  diagnosis. 

Chapter  III  covers  the  theoretical  development  of  the  system  status  monitor  model.  Here, 
the  diagnostic  and  aircraft  functional  hierarchies  are  developed,  knowledge  representation  issues 
are  discussed,  and  methods  of  diagnostic  reasoning  are  explored. 

Development  of  the  system  status  monitor  demonstration  program  is  presented  in  Chapter 
IV.  First,  the  potential  solution  approaches  are  compared,  and  the  reasons  for  choosing  Faultfinder 
as  the  basis  for  the  NASP  System  Status  Monitor  are  explained.  Next,  the  task  of  transforming 
Faultfinder  into  the  NASP  SSM  is  described.  This  description  includes  the  representation  of  the 
aircraft’s  physical  and  functional  interrelationships,  the  format  of  the  status  monitor  displays,  and 
logic  of  the  diagnosis  and  remediation  algorithms. 

In  Chapter  V,  performance  of  the  prototype  syst •  m  status  monitor  is  discussed.  This  dis¬ 
cussion  includes  results  of  test  runs  using  simulated  fault  symptom  inputs.  Finally.  Chapter  VI 
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II.  Problem  Analysis 


2.1  Problem  Definition 

The  problem  to  be  addressed  in  this  study  can  be  divided  intr,  two  related  issues:  1)  Why 
does  the  National  Aerospace  Plane  need  a  system  status  monitor,  and  2)  What  should  the  system 
status  monitor  do9 

2.1.1  NASP  Domain  The  National  Aerospace  Plane  (N'ASP)  will  be  a  revolutionary  trans¬ 
portation  system,  capable  of  taking-off  and  landing  horizontally  on  a  conventional  runway  anil 
ascending  directly  into  orbit  or  cruising  at  6  to  12  times  the  speed  of  sound  at  altitudes  greater 
than  100.000  feet  [22]. 

To  perform  its  intended  mission,  the  NASP  must  be  extremely  efficient,  requiring  some  or 
all  of  its  subsystems  to  perform  multiple  tasks.  Examples  of  mult i-purpose  subsystems  are  the 
fuel  system,  where  the  cryogenic  fuel  may  be  circulated  through  hot  structures  to  provide  active 
cooling,  and  the  forward  fuselage,  which  may  also  serve  as  part  of  the  engine  inlet  structure. 

This  interdependency  of  the  aircraft  systems  will  complicate  the  aircrew's  normal  system 
monitoring  task.  The  effects  of  a  fault  in  a  particular  system  will  probably  not  stay  within  that 
system,  but  will  propagate  to  other  systems.  As  aircraft  systems  become  more  complex  and  in¬ 
terdependent,  the  possible  ramifications  of  any  single  fault  on  other  aircraft  systems  become  more 
complex  and  more  difficult  to  trace. 

The  extremely  large  operational  flight  envelope  of  the  NASP  places  added  demands  on  the 
flight  crew  in  two  ways.  Operation  in  one  flight  phase,  such  as  takeoff,  may  require  the  aircraft 
systems  to  perform  in  much  different  ways  than  in  another  flight  phase,  such  as  hypersonic  cruise 
A  fault  within  a  system  may  not  greatly  affect  the  current  flight  phase,  but  may  preclude  successful 
completion  of  a  later  flight  phase  These  interrelationships  must  all  he  considered  when  assc^sinu 


the  status  of  the  aircraft 
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The  other  area  where  the  large  flight  envelope  of  the  NASP  comes  into  play  is  real-time 
ground-based  support.  In  the  past,  manned  space  vehicles  such  as  Mercury,  Gemini,  Apollo,  and 
the  Space  Shuttle  have  had  extensive  system  monitoring  support  by  personnel  and  equipment  on 
the  ground.  This  ground-based  support  was  realized  through  worldwide  communications  networks. 
The  NASP  may  not  have  the  luxury  of  this  extensive  ground-based  support,  and  therefore  an 
on-board  system  status  monitoring  capability  may  be  required. 

System  complexity,  interdependence,  the  large  flight  envelope,  and  the  requirement  for  au¬ 
tonomous  operations,  along  with  the  speed  with  which  events  occur  during  hypersonic  flight,  will 
combine  to  dictate  the  automation  of  NASP  system  status  monitoring. 


2.1.2  Stains  Monitor  Functions  Once  the  need  for  an  automated  system  status  monitor  has 
been  established,  the  form  and  function  of  the  status  monitor  must  be  defined. 

As  the  name  implies,  a  system  status  monitor  should  keep  the  flight  crew  appraised  of  the 
status  of  the  aircraft  systems.  The  monitor  will  need  to  keep  track  of  the  state  of  sensors  which 
measure  various  aircraft  parameters.  If  any  sensor  reports  an  abnormal  reading,  the  monitor  should 
diagnose  the  cause  of  the  abnormality.  While  monitoring  is  a  straightforward  process,  diagnosis 
can  be  a  very  difficult  task  when  applied  to  even  a  moderately  complex  mechanical  system.  The 
collective  processes  of  monitoring  and  diagnosis  traditionally  have  been  simply  called  diagnosis 
Chapter  III  will  discuss  how  this  two  step  diagnostic  process  can  be  extended  to  provide  additional 
information  for  the  flight  crew 

The  complexity  and  interdependence  of  the  NASP  systems  would  further  imply  that  the 
status  monitoring  task  cannot  be  applied  to  each  individual  system  as  if  it  were  operating  alone 
A  NASP  system  status  monitor  will  need  to  operate  in  the  context  of  the  aircraft  as  a  collection  of 
closely  coupled,  tightly  knit  systems 

The  part  icular  problem  this  st  inly  will  address  is  t  he  design  and  implement  at  imi  •  a  sy  stem 
status  monitor  that  can  perform  extended  diagnostic  functions  on  a  complex  aircraft  with  highly 
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interdependent  systems. 


2.  2  Literature  Review 

Since  the  diagnostic  process  forms  the  basis  for  system  status  monitoring,  this  literature 
review  will  concentrate  on  diagnosis.  The  literature  related  to  the  blackboard  problem-solving 
model  will  also  be  reviewed. 

Diagnosis  is  usually  defined  in  medical  terms  as  “the  act  or  process  of  identifying  or  deter¬ 
mining  the  nature  of  a  disease  through  examination  [12,  363].”  In  recent  years,  the  meaning  and 
application  of  diagnosis  have  been  expanded  to  included  the  domain  of  mechanical  and  electrical 
devices.  In  this  context,  diagnosis  can  be  defined  as  the  use  of  “situation  descriptions,  behavior 
characteristics,  or  knowledge  about  component  design  to  infer  probable  causes  of  system  malfunc¬ 
tions”  [23,  34], 

In  both  the  medical  and  engineering  fields,  diagnosis  has  traditionally  been  a  manual  effort 
performed  by  a  human  expert  in  that  field.  10  improve  the  quality  of  diagnosis  in  the  medical  field, 
and  to  cope  with  increasingly  complex  systems  in  the  engineering  field,  researchers  are  currently- 
investigating  automated  diagnostic  tools.  These  automated  tools  usually  take  the  form  of  "expert 
systems.”  While  manual  diagnosis  forms  the  basis  for  most  of  the  theory  of  diagnosis,  this  review 
will  concentrate  primarily  on  the  current  research  into  automated  diagnosis 

2  2.1  Automated  Medical  Diagnosis  One  of  the  first  and  best-known  medical  diagnostic 
expert  systems  is  MYCIN.  It  was  designed  to  diagnose  infectious  blood  diseases  and  to  help  the 
physician  select  the  correct  type  and  dosage  of  a  drug  treatment  MYCIN  is  a  rule-based  system 
that  uses  a  backward  chaining  technique  to  reason  from  the  patient's  observed  condition  (the 
symptoms)  to  the  identity  of  the  infecting  organism  (the  cause)  The  system  was  developed  at 
Stanford  l  inversitv.  and  work  on  this  project  by  Short liffe.  Axlitie.  Buchanan,  Merigan.  and  Cohen 


was  reported  in  the  literature  as  early  as  1973  [20],  MYCIN  has  served  as  a  model  or  inspiration  for 
several  other  medical  diagnostic  expert  systems,  including  EMYCIN  and  NEOMYCIN  [23,  326]. 


The  DIALOG  (for  DIAgnostic  LOGic)  system,  reported  by  Pople,  Myers,  and  Miller  [17], 
takes  a  more  sophisticated  approach  to  the  medical  diagnosis  problem.  It  was  designed  to  imitate 
the  data  structures  and  diagnostic  reasoning  processes  used  by  a  knowledgable  internist.  The 
DIALOG  system  was  able  to  correctly  diagnose  multiple  (related  or  unrelated)  diseases  in  the  same 
patient.  DIALOG  demonstrated  accurate  diagnostic  performance  in  cases  involving  as  many  as 
five  distinct  diseases  [17,  8-18]. 

Rather  than  to  simply  search  through  a  state-space  as  did  MYCIN,  DIALOG  developed 
hypotheses  about  the  causes  of  observed  patient  symptoms,  and  partitioned  those  hypotheses  into 
disjoint  sets.  A  form  of  deductive  inference  called  abduction  was  then  used  to  sequentially  step 
through  the  sets  of  hypotheses,  accepting  the  correct  hypotheses  and  reject  the  incorrect  hypotheses. 
The  method  of  abduction  required  that  DIALOG  have  control  structures  to  deal  with  the  following 
four  issues: 

1  Observations  must  be  able  to  'trigger'  or  evoke  hypotheses  of  disease  entities  with 
which  they  are  associated. 

2.  Hypotheses  must  be  able  to  generate  expectations  concerning  likely  consequences, 
which  may  be  posed  as  questions  regarding  additional  observations  in  order  to 

test'  the  hypotheses. 

3  It  is  necessary  to  provide  some  means  for  deciding  among  contending  hypotheses. 

4.  Some  means  must  be  developed  to  group  hypotheses  into  mutually  exclusive  subsets 
corresponding  to  coherent  problem  areas  [17,  849] 

DIALOG'S  data  structures  consisted  of  three  primary  relationships  to  represent  dependencies 
inherent  in  the  internal  medicine  problem  domain.  These  were 

1  Manifestation  (M)  evokes  disease  (D). 

2  Disease  (D)  is  manifested  by  manifestation  (M).  and 


3  One  disease  (1)1  1)  is  a  form  of  another  disease  ( I)  1 ) 


These  relationships  were  organized  into  a  network  to  represent  the  hierarchy  of  diseases  ami 
the  associated  manifestations.  In  the  network,  the  diseases  were  represented  as  nodes,  and  each  of 
the  three  relationships  above  were  represented  as  directed  arcs  connecting  the  nodes  The  network 


also  contained  two  different  weighting  factors: 

1.  The  likelihood  that  a  certain  disease  is  the  cause  of  a  particular  manifestation,  and 

2.  The  frequency  with  which  a  patient  with  a  particular  disease  will  display  a  certain  manifes¬ 
tation. 

The  weighting  factors  allowed  DIALOG  to  choose  the  most  likely  of  two  or  more  competing 
hypothetic  diagnoses  [17,  849-850], 

Pople  expanded  on  his  work  with  DIALOG  by  developing  the  INTERNIST-  II  medical  di¬ 
agnostic  system  [16]  Its  area  of  expertise  was  also  internal  medicine  INTERN IST-II  was  one  of 
the  most  extensive  medical  diagnostic  expert  systems,  with  desciptions  of  more  than  500  separate 
diseases  and  more  than  3500  disease  manifestations  [23,  281] 

INTERNIST-II’s  major  improvement  over  DIALOG  was  its  ability  to  simultaneously  view 
the  disjoint  sets  of  hypotheses  and  reason  over  the  entire  group  of  sets  This  allowed  it  to  more 
quickly  converge  on  a  correct  diagnosis  and,  in  some  cases,  yield  a  more  accurate  result  [16.  1030] 

In  addition  to  the  hierarchical  networks  of  diseases  and  their  manifestations  used  by  DIALOG 
and  INTERNIST-II.  the  next  generation  of  n  ledical  diagnostic  expert  systems  also  incorporated 
models  of  general  human  physiological  knowledge  and  specific  information  about  the  patient's 
physical  state.  One  such  system  was  ABEL  [15.  893],  which  aided  in  the  diagnosis  of  electolyte  and 
acid-base  disturbances. 

ABEL  incorporated  two  unique  features  which  set  it  apart  from  DIALOG  and  INTERNIST 
II  first,  it  used  its  general  and  specific  physiological  knowledge  to  define  what  was  c.dhd  the 
pat ieiit-specifir  model  Next,  this  model  was  used  to  construct  and  refine  a  multi  |e\.|  n>iw  -rk 
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that  represented  not  just  the  simple  associations  between  disorders  and  their  manifestations,  but 
also  their  causal  relationships.  It  is  this  model  of  the  patient  s  current  state  of  health  and  the 
understanding  of  the  cause  of  deviations  from  a  normal  state  of  health  that  make  ABLL  more 
sophisticated  than  its  predecessors  [15], 

\1DX  was  a  medical  diagnosis  system  developed  at  Ohio  State  University  by  B.  Chan- 
drasekaran  and  others.  Its  primary  domain  was  a  liver  syndrome  called  cholestasis.  MDX  used  a 
hierarchical  knowledge  organization  which  was  operated  upon  by  a  collection  of  “cooperating  ex¬ 
perts."  These  experts  communicated  with  each  other  through  a  blackboard  structure  [1]  This  type 
of  knowledge-based  diagnosis  system  is  very  similar  to  the  conceptual  structure  of  the  proposed 
NASP  system  status  monitor. 


2.2.2  Automated  Hardware  Diagnosis  Expert  systems  for  the  diagnosis  of  electronic  hard¬ 
ware  faults  are  descendants  of  the  medical  diagnostic  systems  mentioned  in  the  preceeding  section 
As  such,  they  have  benefited  from  the  evolution  of  the  medical  diagnostic  systems  and  incorporate 
the  most  sophisticated  and  powerful  features  of  the  medical  systems  As  one  might  expect,  the 
>tudy  of  the  hardware  diagnostic  process  has  led  to  the  discovery  of  new  and  betipr  ways  to  perform 
the  general  diagnostic  task 

An  example  of  the  current  work  in  expert  systems  for  hardware  diagnosis  is  reported  by 
Bandall  Davis  of  the  Artificial  Intelligence  Laboratory  at  the  Massachusetts  Institute  of  Technology 
[3]  Davis  embraces  the  idea  that  a  diagnostic  system  will  benefit  from  a  causal  understanding  of 
the  structure  and  function  of  the  malfunctioning  device  in  question  He  adds  two  principles  to 
the  theory  of  diagnosis  These  principles  are  layering  the  paths  of  interaction  and  the  concept  of 
locality  [3.  88], 

Davis  represents  the  function  and  structure  of  the  device  as  paths  of  causal  interaction  Iliese 
pal  hs  define  the  possible  interact  toils  bet  ween  any  pair  of  the  device  s  comp<  men  l  s  In  normal  ■  p.  r 
item  there  are  a  certain  number  of  probable  interactions  between  components  and  Hi  additional 


.-'s/ -.  V 


'  s  v'^V.'.vV- 


number  of  possible  but  much  less  likely  interactions.  When  also  considering  fault  situations,  the 
number  of  possible  interactions  becomes  much  larger.  The  paths  of  interaction  are  used  to  generate 
candidates  to  determine  which  components  are  causing  a  fault.  If  every  conceivable  interaction 
path  is  considered,  the  number  of  candidates  to  examine  will  become  unwieldy.  Conversely,  if 
the  number  of  interaction  paths  is  too  restricted,  some  entire  classes  of  candidates  many  never  be 
considered. 

Layering  the  paths  of  interaction  is  used  as  a  compromise  between  having  too  many  and  too 
few  interaction  paths.  Each  layer  uses  a  different  set  of  interaction  paths  to  represent  a  different 
model  of  the  device.  By  layering  the  models,  the  most  restrictive  model  is  considered  first,  and  a 
less  restrictive  model  is  considered  only  if  the  first  yields  a  contradiction  [3,  90-93], 

The  concept  of  locality  holds  that  the  most  appropriate  representation  of  the  malfunctioning 
device  will  be  the  one  in  which  the  cause  and  symptom  of  the  fault  are  adjacent,  or  "local"  to 
each  other  Therefore,  an  electrical  adjacency  representation  would  be  appropriate  for  a  continuity 
fault,  while  a  thermal  adjacency  representation  would  be  more  appropriate  for  a  fault  caused  by 
heating  [3,  94], 


2.2.3  Hardware  Diagnosis  in  the  Flight  Domain  Hardware  diagnostic  systems  being  devel¬ 
oped  for  application  in  the  flight  domain  have  incorporated  most  of  the  desirable  features  of  the 
diagnostic  systems  examined  so  far  and  have  also  been  enhanced  with  new  and  innovative  capabili¬ 
ties  Much  of  this  work  is  being  performed  by  the  National  Aeronautics  and  Space  Administration 
(NASA)  at  the  Dryden  Flight  Research  Facility.  Edwards.  California,  and  the  Langley  Research 
Center.  Langley.  Virginia  [3.19], 

The  research  being  performed  in  the  area  of  expert  system  fault  diagnosis  at  the  Dryden 
Facility  is  in  support  of  the  development  of  advanced  digital  flight  control  systems  The  system 
reported  jn  [•!].  called  the  experimental  expert  system  flight  status  monitor  (1  FSi  SMl.  will  be 
used  by  a  flight  systems  engineer  on  the  ground  to  assess  the  status  of  i  fie  flight  .n  t  r-  ■!  system 
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in  a  remotely  piloted  vehicle.  The  EESFSM  goes  beyond  the  diagnostic  systems  reviewed  thus  far 
in  that  it  incorporates  functions  that  are  performed  both  before  and  after  the  actual  diagnostic 
process.  Before  diagnosis  is  performed,  the  EESFSM  uses  expert  system  knowledge  to  monitor  the 
fault  status  indicator  bits  of  the  flight  control  system  to  detect  the  presence  of  a  fault  symptom. 
The  detected  fault  symptom  then  feeds  the  fault  diagnosis  capability.  The  EESFSM  uses  the  results 
of  the  fault  diagnosis  to  recommend  corrective  actions  and  to  deduce  situations  of  concern  [4,  3], 

In  their  research  [19],  Schutte  and  Abbott  used  a  fault  monitoring  and  diagnosis  system 
similar  to  the  EESFSM,  but  they  extended  its  scope  beyond  the  flight  control  system.  They  have 
developed  a  hierarchy  of  aircraft  “goals,”  with  the  proper  functioning  of  a  subsystem  being  the 
lowest  level  of  the  hierarchy.  A  group  of  subsystems  makes  up  the  flight  control  system,  which  in 
turn  is  one  factor  contributing  to  the  flight  dynamics  of  the  aircraft.  The  next  two  levels  in  the 
hierarchy  are  the  aircraft  trajectory  and  route,  in  that  order  [19,  3].  When  the  diagnostics  function 
of  this  system  identifies  a  fault,  it  can  also  determine  the  effect  of  that  fault  on  the  accomplishment 
of  the  other  goals  in  the  hierarchy. 

S.  2.i  Trends  in  Automated  Diagnosis  Automated  diagnostic  systems  began  as  expert  sys¬ 
tems.  with  each  fault  situation  represented  m  a  separate  rule  As  this  literature  review  suggests, 
the  trend  in  automated  diagnosis  is  toward  a  deeper  representation  of  system  knowledge.  The 
deeper  knowledge  generally  represents  the  normal  operation  and  interaction  of  the  system  rather 
than  specific  fault  situations 

2. 2. ,5  Blackboard  .'-'ystems  The  blackboard  problem-solving  model  was  first  used  in  the 
HF.ARSAY  II  speech  understanding  system  developed  m  the  early  1970's  by  Ertnati  and  others 
[5]  Since  then  blackboards  have  been  used  in  a  wide  variety  of  applications,  and  each  time  in  a 
slightly  different  form  [*<  2] 

A  blackboard  architecture  refers  to  a  fairly  simple  concept  that  has  been  tailored  to  meet 


the  specific  needs  of  its  users.  In  its  simplest  form,  a  blackboard  is  a  central  database  that  can 
be  accessed  by  independent  program  modules.  These  modules  are  called  knowledge  sources,  and 
usually  take  the  form  of  expert  systems  One  of  the  knowledge  sources  usually  acts  as  the  controller 
to  determine  which  knowledge  source  will  be  permitted  to  have  access  to  the  blackboard  next.  The 
blackboard  serves  as  the  only  means  for  the  knowledge  sources  to  communicate.  If  a  knowledge 
source  needs  information,  it  looks  for  it  in  the  blackboard.  If  a  knowledge  source  can  supply 
information,  it  posts  that  information  to  the  blackboard  for  all  other  knowledge  sources  to  see. 
In  this  way,  the  blackboard  model  supports  incremental,  opportunistic  problem  solving.  Each 
knowledge  source  contributes  its  own  small  part  of  the  problem  solution,  and  does  it  only  when  its 
necessary  inputs  have  appeared  in  the  blackboard. 

The  interested  reader  can  obtain  a  more  detailed  analysis  of  blackboard  theory  and  applica¬ 
tions  from  the  excellent  papers  by  Hayes-Roth  [9,10,8]  and  Nil  [13,14]. 


III.  Theoretical  Development 


Development  of  the  theory  underlying  the  National  Aerospace  Plane  system  status  monitor 
will  be  covered  in  three  sections  in  this  chapter.  This  discussion  will  center  on  a)  the  diagnostic 
and  functional  hierarchies  which  form  the  framework  of  the  system  status  monitor,  b)  the  semantic 
network  form  of  knowledge  representation  used  here,  and  its  advantages  versus  an  associational  form 
of  knowledge  representation,  and  c)  the  causal  knowledge  representation  and  reasoning  method  used 
in  the  remediation  level  of  the  system  status  monitor.  Specifics  about  how  this  theory  was  applied 
to  the  implementation  of  the  NASP  system  status  monitor  will  be  covered  in  Chapter  IV. 

3.1  Functional  and  Diagnostic  Hierarchies 

As  stated  in  the  previous  chapter,  the  complexity  of  the  NASP  will  require  that  the  system 
status  monitor  provide  as  much  useful  information  as  possible  to  aid  the  flight  crew.  The  diagnostic 
and  functional  hierarchies  defined  here  serve  as  a  framework  for  providing  that  information  to  the 
flight  crew  The  functional  hierarchy  will  be  examined  first 

3.1.1  Functional  Hierarchy  The  functional  hierarchy,  shown  in  Figure  1.  was  derived  from 
the  gual  hierarchy  developed  by  Schutte  and  Abbott  [19],  which  in  turn  developed  from  the  work 
of  Chen  [2],  From  top  to  bottom,  each  level  in  the  functional  hierarchy  is  composed  of  one  or 
more  instances  of  the  level  below  it  Thus,  the  mission  is  composed  of  one  or  more  flight  phases, 
each  flight  phase  has  an  instance  of  the  aircraft  to  perform  it.  and  so  on.  This  expansion  of  the 
hierarchy  is  shown  in  Figure  2.  An  important  point  is  that  each  flight  phase  has  a  different  instance 
of  the  aircraft  because  different  capabilities  of  the  aircraft  are  required  to  accomplish  each  flight 
phase  Likewise,  each  aircraft  instance  has  Us  own  instances  of  each  of  the  individual  aircraft 
systems  This  hierarchical  framework  helps  to  organize  the  knowledge  about  the  aircraft  and  its 
functions  Any  component  or  function  at  any  level  of  the  hierarchy  can  be  associated  easily  with 
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the  components  on  which  it  depends  (lower  levels  in  the  hierarchy)  and  also  with  the  components 
that  are  dependent  on  it  (higher  levels  in  the  hierarchy). 


3.1.2  Diagnostic  Hierarchy  While  this  hierarchy  is  named  for  diagnosis,  the  actual  diagnosis 
function  is  only  one  of  five  levels  in  the  hierarchy.  Figure  3  shows  the  diagnosis  hierarchy  and  the 
relative  positions  of  the  five  levels.  To  avoid  confusion,  the  collection  of  all  five  levels  will  be  called 
the  “diagnostic  process."  and  the  second  level  of  the  diagnostic  process  will  be  called  the  “diagnosis 
function."  The  entire  diagnostic  process  is  performed  bottom-up,  with  each  level  supplying  its 
output  information  as  input  to  the  next  higher  level. 

The  definition  of  diagnosis  used  in  the  previous  chapter  was  “to  infer  probable  causes  of 
system  malfunctions.”  This  definition  implies  that  there  be  a  method  for  determining  if  a  system 
malfunction  indeed  occurred.  This  is  the  function  of  the  first  diagnostic  level,  monitoring. 


3. 1.2.1  Monitoring  The  overall  diagnostic  process  is  started  by  monitoring  the  phys¬ 
ical  system  in  question.  The  monitor  must  be  able  to  detect  a  fault  condition  and  report  it  to  the 
next  level  in  the  diagnostic  hierarchy.  To  do  this,  the  monitor  must  first  be  able  to  discriminate 
fault  conditions  from  normal  conditions.  Since  normal  operating  conditions  are  usually  understood 
better  than  fault  conditions,  the  monitor  usually  starts  with  a  model  of  the  normal  operation  of 
the  physical  system.  This  model  takes  the  form  of  a  numerical  simulation  of  the  operation  of  the 
physical  system  Readings  from  sensors  in  the  physical  system  arp  compared  to  values  that  are 
predicted  by  the  numerical  simulation.  If  the  sensed  values  fall  outside  of  a  range  of  acceptable 
predicted  values,  then  a  fault  has  occurred  and  it  is  reported 

In  the  case  of  the  NASP.  the  fault  monitor  must  contain  numerical  simulations  that  also 
account  for  the  different  flight  phases.  As  an  example,  the  model  of  the  encmes  must  predi.  t  a 
different  range  of  normal  readings  for  the  takeoff  phase  than  it  w..uld  fi>r  tie-  hyp.  rsom.  cruise 
phase. 
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To  provide  a  meaningful  input  to  the  levels  in  the  diagnostic  hierarchy  which  use  symbolic 
processing,  the  monitor  must  also  convert  its  quantitative  assessment  of  the  fault  situation  to  a 
qualitative  fault  symptom.  For  example,  an  engine  temperature  sensor  reading  that  is  75  degrees 
higher  than  the  normal  range  would  be  reported  as  “Engine  Temperature  Too  High."  This  qual¬ 
itative  fault  symptom  will  serve  as  an  input  to  the  diagnosis  level  of  the  hierarchy,  where  the 
implications  of  the  symptom  will  be  determined. 


3. 1.2. 2  Diagnosis  As  was  discussed  in  the  previous  chapter,  there  are  a  variety  of 
ways  that  diagnosis  can  be  accomplished,  but  they  all  have  the  same  goal.  Given  a  set  of  fault 
symptoms,  the  diagnosis  function  must  try  to  determine  the  root  cause  of  those  symptoms. 

Ideally,  the  diagnosis  function  should  isolate  a  single  faulty  primitive  component  which  is 
responsible  for  all  the  observed  fault  symptoms.  (In  this  context,  a  primitive  component  is  defined 
as  a  component  that  is  not  made  up  of  other  components,  and  therefore  is  at  the  bottom  of  the 
functional  hierarchy.  Primitive  components  are  assembled  to  form  composite  components,  which 
themselves  can  be  assembled  to  eventually  form  the  entire  aircraft.)  If  this  is  not  possible,  the 
next  best  situation  is  to  isolate  the  fault  to  a  single  composite  component.  The  diagnostic  function 
should  move  up  the  functional  hierarchy  of  the  aircraft  until  it  finds  a  level  at  which  it  can  identify 
a  faulty  component  responsible  for  the  observed  symptoms.  By  starting  at  the  bottom  of  the 
functional  hierarchy,  the  diagnosis  function  strives  to  identify  the  most  primitive,  and  therefore 
the  most  specific,  component  to  explain  the  cause  of  the  observed  fault  symptoms.  Only  after 
it  is  found  that  a  fault  in  one  of  the  primitive  components  cannot  account  for  all  observed  fault 
symptoms  will  the  diagnosis  function  move  up  one  level  of  the  functional  hierarchy  and  attempt  to 
identify  a  faulty  composite  component. 
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A  tradeoff  occurs  when  the  diagnosis  function  must  move  up  the  functional  hierarchy  to  find 
a  suitable  explanation  for  the  fault  symptoms.  The  diagnosis  becomes  less  specific  and  therefore 
less  useful  to  the  next  higher  levels  in  the  diagnostic  hierarchy.  On  the  cither  hand,  moving  up 
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in  the  functional  hierarchy  and  becoming  less  specific  tends  to  increase  the  probability  that  a 
responsible  component  will  be  found  Making  a  less  specific  diagnosis  is  better  than  no  diagnosis 


at  all.  The  tradeoff  is  beneficial  because  identifying  the  malfunctioning  component  is  not  the 
only  task  performed  by  the  diagnosis  function.  The  diagnosis  function  also  determines  the  other 
components  in  the  functional  hierarchy  whose  performance  is  probably  or  potentially  affected  by 
the  faulty  component.  This  ability  to  not  only  determine  the  cause  of  a  set  of  fault  symptoms, 
but  to  determine  the  side  effects  of  the  fault,  is  of  great  benefit  to  the  flight  crew  in  assessing  the 
overall  aircraft  status,  and  is  the  basis  for  the  next  higher  levels  of  the  diagnostic  hierarchy. 

3. 1.2. 3  Rtmediation  The  next  logical  step  after  the  monitoring  function  identifies 
fault  symptoms  and  the  diagnosis  function  determines  the  underlying  fault  and  its  side  effects 
is  to  recommend  the  best  course  of  action  given  the  current  situation.  This  is  the  purpose  of  the 
remediation  function. 

While  it  may  appear  simple  to  "remedy  the  situation."  a  remedy  may  take  a  number  of 
different  forms  depending  on  when  it  is  applied  and  the  intended  outcome  Two  opposite  approaches 
are  to  a)  compensate  for  the  current  set  of  fault  symptoms  (treating  the  symptoms),  or  b)  remote 
the  source  of  the  current  set  of  fault  symptoms  (treating  the  causes)  Either  one  of  these  approaches 
can  be  employed  for  a  variety  of  reasons,  including  to; 

1.  Conserve  resources, 

2.  Prevent  further  malfunctions, 

3.  Ensure  mission  accomplishment, 

4.  Ensure  crew  safety,  or 

5.  Ensure  aircraft  safety. 


for  tin*  purposes  of  this  study,  a  single  remediation  approach  and  a  single  reason  were  eliosei 


to  be  implemented  in  the  NASI'  svstem  slams  monitor  It  was  derided  the  remediation  filin'- 
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tion  should  seek  to  compensate  for  the  current  set  of  fault  symptoms  in  order  to  ensure  mission 
accomplishment. 

In  contrast  to  the  diagnosis  function,  where  fault  hypothesis  generation  used  a  bottom-up 
approach  on  the  functional  hierarchy,  the  remediation  function  should  use  a  top-down  approach. 
In  a  fault  situation,  remediation  will  attempt  to  deal  first  with  the  symptom  that  is  having  the 
most  immediate  effect  on  the  highest  affected  level  of  the  functional  hierarchy.  Since  the  stated  goal 
of  the  remediation  function  is  to  ensure  mission  accomplishment,  this  method  will  work  to  relieve 
the  symptom  that  is  most  threatening  to  the  mission.  From  this  point,  the  remediation  function 
should  search  for  the  lowest-level,  or  most  primitive,  action  that  will  produce  the  desired  effect  on 
the  most  threatening  symptom. 


3. 1.2.4  Prediction  Before  the  corrective  action  proposed  by  the  remediation  function 
can  be  put  into  effect,  the  status  monitor  needs  to  determine  the  possible  consequences  of  the 
proposed  action.  Although  the  remedial  action  is  intended  to  compensate  for  the  detrimental 
effects  of  the  fault  symptoms,  it  may  have  other  side  effects  that  will  make  the  fault  situation 
worse  or  produce  a  completely  different  fault  situation.  The  new  system  status  resulting  from  the 
remedial  action  must  be  compared  to  a  status  which  is  normal  for  the  current  flight  phase.  If  a 
fault  situation  is  found  in  the  predicted  status,  the  proposed  remedial  actions  must  be  discarded 
This  is  the  purpose  of  the  prediction  function. 

It  should  be  stressed  that  the  prediction  function  will  deal  only  with  the  immediate  conse¬ 
quences  of  the  proposed  remedial  action.  If  the  prediction  function  finds  the  proposed  action  to  be 
unacceptable,  it  will  request  that  the  remediation  function  develop  a  different  remedial  action  for 
the  prediction  function  to  test.  This  process  will  continue  until  an  acceptable  remedial  action  is 
found  At  this  point,  the  acceptable  action  is  sent  to  the  planning  function 
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3. 1.2.5  Planning  The  purpose  of  the  planning  function  is  to  determine  the  long-range 
consequences  of  the  proposed  remedial  action.  The  ultimate  question  to  be  answered  by  this 
function  is  if  the  consequences  of  the  remedial  action  will  allow  completion  of  the  mission.  If  the 
action  proposed  by  the  remediation  function  is  consistent  with  the  mission  objectives,  that  action 
will  be  presented  to  the  flight  crew  for  their  approval.  If  the  proposed  action  jeopardizes  any  aspect 
of  the  mission,  the  action  will  be  rejected  and  the  remediation  function  will  be  asked  to  propose 
a  different  action.  If  the  proposed  action  is  acceptable,  it  will  be  carried  out.  Depending  on  the 
circumstances,  an  acceptable  action  may  produce  a  wide  range  of  outcomes.  On  one  hand,  the 
action  may  allow  the  mission  to  be  completed  with  all  objectives  met.  At  the  other  extreme,  the 
best  course  of  action  may  be  to  abort  the  mission  and  “cut  the  losses.”  The  planning  function 
should  pick  the  best  alternative  while  working  within  any  constraints  imposed  by  considerations 
such  as  safety,  cost,  security,  etc. 

Figure  4  shows  the  sequence  of  steps  that  the  system  status  monitor  takes  in  trying  to  resolve 
an  observed  fault  situation. 

3.2  Semantic  Xetwork  Knowledge  Representation 

The  physical  and  functional  relationships  that  make  up  the  National  Aerospace  Plane  domain 
are  organized  in  a  semantic  network  representation.  This  representation  is  virtually  the  same  as  is 
used  in  the  Faultfinder  system  developed  at  NASA  Langley  Research  Center.  (Faultfinder  will  be 
discussed  further  in  the  Chapter  IV.)  However,  a  number  of  changes  and  additions  were  made  to 
accommodate  the  additional  capabilities  of  the  NASP  system  status  monitor 

Semantic  networks  were  originally  develop  d  as  a  way  of  representing  the  meaning  of  Knglish 
words  [18,  215],  The  objects  to  be  represented  are  the  nodes  of  the  network,  and  the  relationships 
between  the  objects  are  the  arcs  connecting  the  nodes.  Each  arc  has  a  direction  to  signify  the 
direction  of  the  relationship  Two-way  relationships  must  be  expressed  explicitly 
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Specific  objects  in  a  semantic  network  can  be  shown  to  belong  to  a  general  class  of  objects 
through  an  IS-A  relationship  That  is  to  say  that  the  object  “is  a"  specific  instance  of  the  general 
class  of  objects.  Figure  5  shows  the  object  classes  used  in  the  NASP  system  status  monitor 
knowledge  base  and  the  specific  object  instances  in  each  of  those  classes  of  objects. 

The  content  of  a  particular  semantic  network  not  only  depends  on  the  objects  to  be  repre¬ 
sented.  but  also  on  the  reasoning  to  be  applied  to  the  network.  As  an  example,  reasoning  about 
the  parts  that  make  up  a  device  would  require  arcs  named  PARTS  from  the  device  object  to  the 
individual  part  objects.  The  diagnosis  function  of  the  NASP  system  status  monitor  incorporates 
reasoning  about  the  physical  make-up  and  functional  dependencies  of  the  NASP  aircraft.  There¬ 
fore,  the  knowledge  base  in  the  system  status  monitor  is  represented  in  those  terms.  Figure  6  shows 
the  relationships  used  in  the  NASP  system  status  monitor  knowledge  base. 

The  remediation  function  of  the  NASP  system  status  monitor  performs  reasoning  about 
actions  that  will  produce  changes  in  the  observed  values  of  sensors.  Therefore,  the  NASP  knowledge 
base  also  includes  causal  information  to  facilitate  this  reasoning.  The  next  section  describes  this 
causal  reasoning  representation. 

d.'l  Causal  Knowledge  and  Reasoning 

The  knowledge  used  by  the  remediation  function  of  the  NASP  system  status  monitor  is 
contained  in  the  semantic  network  knowledge  base  and  is  associated  with  the  sensor  objects.  The 
intent  is  to  represent  a  set  of  actions  that  will  cause  a  predictable  change  in  the  sensor  reading. 
This  usually  involves  altering  the  conditions  that  the  sensor  is  measuring.  As  an  example,  the 
airspeed  sensor  measures  airspeed.  The  causal  knowledge  attached  to  the  airspeed  sensor  in  the 
knowledge  base  will  include  those  actions  that  can  affect  airspeed.  These  would  include  increasing 
or  decreasing  thrust,  increasing  or  decreasing  drag,  etc. 

Causal  reasoning  in  this  system  involves  chaining  together  a  series  of  cause  and  ■■Ifeci  pairs 


Object  Instances 


Mission  .  Mission 


Flight-Phase 


Flight-Parameter 


Takeoff 

Climb 

Cruise 

Descent 

Landing 

Total-Thrust 

Weight 

Drag 

Attitude 
Li  f  t 


Ai rcraf  t -Sensor 


Plane 


Ai  rcraf  t  -Sys  tern 


Ai rspeedA 
Al t i tudeA 
Climb-RateA 
MachA 

Sink-RateA 
Pi tchA 
RollA 
YavA 

Takeoff-Plane 

Climb-Plane 

Cruise-Plane 

Descent-Plane 

Landing-Plane 

Propuls  ion- Sys  temA 
Hydraulic -Sys temA 
Fuel-SystemA 
Flight-Control-SysA 
Thermal -Pro  tec  t ion-SysA 


Engine 


Engine-Sensor 


EngineA 

EngineB 

N1 A ,  B 
EprA,  B 
EgtA,  B 
VoltageA,  B 
ThrustA,  B 
VibrationA,  B 


Engine  Component 


InletA,  B 
CompressorA,  B 
GearboxA,  B 

Electric-GeneratorA,  B 
Gas-GeneratorA,  B 
TurbineA,  B 
Fuel-InjectorA,  B 
CombustorA,  B 
NozzleA,  B 


Hydraulic-Subsystem 
Hydraulic-Line  .  . 
Hydraulic-Pump  .  . 


Hyd-Pressure 


Hydraulic-Resevoi r 
Hyd-Quantity  .  . 


Hydraul ic-Subsys temA 
Hydraulic-SubsystemB 

Hydraul ic-LineA 
Hydraulic-LineB 

Engine-Hyd-PumpAl 

Engine-Hyd-PumpBl 

Electric-Hyd-PumpA2 

Electric-Hyd-PumpB2 

Hyd-PumpAl- Pressure 
Hyd-PumpA2 -Pressure 
Hyd-PumpBl -Pressure 
Hyd-PumpB2 -Pressure 

Hydraulic-Resevoi rA 
Hydraulic-Resevoi rB 

Hyd-QuantityA 
Hyd-Quant i tyB 


Fuel-Tank  .  Fvd-Fuel-Tank 

Aft-Fuel-Tank 
Eng ineA- Feed -Tank 
Eng ineB- Feed -Tank 

Fwd-Tank-Transf er-Pump 
Af  t -Tank-Transfer-Pump 
Eng ineA -Tank- Boos  t- Pump 
Eng ineB -Tank- Boos  t -Pump 


Fuel-Pump 


Object  Class  Object  Instances 

Fuel-Valve  .  Crossfeed-Valve 

Fuel-Dump-ValveA 

Fuel-Dump-ValveB 

Fuel-Line  .  Fuel-LineA 

Fuel-LineB 

Fuel-Flov  .  Fuel-FlovA 

Fuel-FlowB 

Fuel-Qty-Sensor  .  Fvd-Tank-Quanti ty 

Af  t-Tank-Quant i ty 
Feed-TankA-Quan  t i ty 
Feed-TankB-Quanti ty 
Total-Fuel-Quanti ty 
Fuel-Imbalance 

Control-Surface  .  Left-Elevon 

Right-Elevon 

Body-Flap 

Rudder 

Control-Surface-Actuator  .  Lef t-Elevon-Actuator-1 ,  2 

Right-Elevon-Actuator-1 ,  2 
Body-Flap-Actuator-1,  2 
Rudder-Actuator-1,  2 

Control-Surface-Fosi tion  .  Lef t-Elevon-Posi tion 

Right-Elevon-Posi tion 
Body-Flap-Posi tion 
Rudder-Posi tion 

Cooling-Subsystem  .  Nosecap-Cooling 

Lef  t -Wing-Cooling 
Right-Ving-Cooling 
Engine- In  let -Coo  ling 
EngineA-Internal- Cooling 
EngineB-In ternal-Cool ing 
Engine-Nozzle -Coo  ling 
Ver t-Tai 1 -Cool ing 
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Object  Class 

Object  Instances 

Cooling-Pump  . 

.  Fvd-Hyd-Cooling-Pump 

Fud- Elec -Coo ling- Pump 

Lef  t-Hyd-Cool ing-Pump 

Lef  t -Elec -Coo ling- Pump 

Righ t-Hyd-Cool ing-Pump 

Right -Elec -Coo ling- Pump 

Temp-Sensor  . 

Lef  t-Uing-Temp 

Right-Ving-Temp 

Engine-Inlet-Temp 

Eng ineA- Internal -Temp 

Eng ineB-In ternal -Temp 
Engine-Nozzle-Temp 

Vert-Tail-Temp 

Cooling-Pressure  .  .  . 

Fvd -Elec -Coo  1 ing- Pressure 
Left-Hyd -Coo ling-Pressure 

Left -Elec-Cool ing- Pressure 

Righ t-Hyd-Cool ing- Pres sure 
Right-Elec-Coo  ling -Pressure 

Figure  5.  Object  Cl. L>ses  in  the  Semantic  Network  Knowledge  Base  ami  t : ; •  *  Oi  j •  ■  e t  Instance  i 
Each  Class  (continued) 
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Figure  C.  Semani  ic  Network  Relationships. 

The  goal  is  to  reach,  at  the  end  of  the  chain,  the  most  fundamental  action  that  will  ultimately 
cause  the  desired  change  in  the  sensor  reading  at  the  head  of  the  chain. 

The  causal  reasoning  process  can  best  be  explained  with  an  example.  If  the  NASP  mission  is 
being  threatened  by  a  low  climb  rate  in  the  climb  flight  phase,  something  must  be  found  to  increase 
the  climb  rate.  One  option  is  to  increase  engine  thrust.  So  now  a  further  action  must  be  found  to 
increase  thrust.  This  chaining  process  will  continue  until  finding  the  most  elementary  action  which 
will  produce  the  desired  result 

Since  several  different  chains  of  actions  may  produce  the  same  desired  result,  some  method 
must  be  employed  to  decide  which  actions  to  choose.  Some  logical  alternatives  are  to  choose: 

1.  Actions  that  most  directly  affect  the  diagnosed  fault  component. 

2.  Actions  which  counteract  the  greatest  number  of  fault  symptoms, 

3  Actions  which  th-  rtt'-  iv -'s  expend  the  h  a-t  resources,  e*.- 
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IV.  Program  Developrnt  nt 


The  theoretical  basis  for  the  National  Aerospace  Plane  (NASP)  system  status  monitor  was 
explained  in  the  previous  chapter.  This  chapter  will  describe  the  development  of  a  computer 
program  prototype  for  a  NASP  system  status  monitor  that  implements  those  theories. 

The  first  section  of  this  chapter  lists  the  alternatives  explored  for  a  suitable  development 
environment  for  the  prototype  system  status  monitor  The  next  section  describes  the  knowledge 
base  used  to  represent  the  NASP  domain.  The  last  three  sections  outline  the  monitoring,  diagnosis, 
and  remediation  functions  which  use  the  knowledge  base. 

4-1  Possible  Programming  Approaches 

Several  computer  programming  techniques  were  explored  for  the  development  of  the  prototype 
NASP  system  status  monitor.  These  included  off-the-shelf  expert  system  shells,  blackboard  system 
shells,  and  a  dedicated  aircraft  diagnosis  system  called  Faultfinder  which  was  ultimately  chosen. 

4.11  Erpert  System  Shells  The  first  approach  investigated  for  implementation  of  the  system 
status  monitor  was  standard  expert  system  shells.  The  two  systems  most  seriously  considered  were 
the  Automated  Reasoning  Tool  (ART)  developed  by  Inference  Corporation,  and  the  Knowledge 
Engineering  Environment  (KEE)  developed  by  Intellicorp.  Both  of  these  systems  offer  a  very  rich 
development  environment,  with  excellent  editing  and  debugging  facilities.  ART  is  primarily  rule- 
based,  while  KEE  uses  a  frame-  and  object-oriented  knowledge  representation.  Either  one  of  these 
systems  could  have  been  an  adequate  method  with  which  to  implement  a  system  status  monitor,  but 
neither  directly  supported  the  blackboard  problem-solving  model  which  was  an  original  requirement 
ut  this  project.  Therefore,  neither  ART  nor  KEE  was  considered  the  first  choice  for  the  system 
status  monitor  development  tool. 


4-1-2  Blackboard  Shells  Three  blackboard  shells  were  considered  as  NASP  system  status 


monitor  programming  tools.  These  were  BB1  (Blackboard  One)  developed  at  Stanford  University 
[T],  ABE  (A  Better  Environment)  developed  by  Teknowledge  Corporation  [6.11],  and  SCHEMER 
developed  by  Dr.  Michael  Fehling  of  Rockwell  International  Science  Center. 

All  three  blackboard  shells  offered  the  ability  to  integrate  the  reasoning  of  separate  knowledge 
sources.  This  capability  corresponded  well  with  the  diagnostic  hierarchy  model.  Each  level  of 
the  hierarchy  could  have  been  implemented  as  a  separate  knowledge  source,  and  the  functional 
hierarchy  could  have  been  mapped  into  a  multi-level  blackboard.  However,  none  of  the  blackboard 
shells  was  available.  BB1  was  ordered  from  Stanford  University  in  May  1987,  but  its  delivery  date 
was  uncertain  and  so  it  could  not  be  considered  the  primary  implementation  choice.  Both  ABE 
and  SCHEMER  were  still  in  development  during  the  summer  of  1987,  making  them  unavailable  for 
this  project. 

4-1.3  Faultfinder  Research  by  Kathy  Abbott  and  Paul  Schutte  in  the  Vehicle  Operations 
Research  Branch,  NASA  Langley  Research  Center,  was  directed  toward  real-time  fault  monitoring 
and  diagnosis  for  commercial  transport  aircraft.  Their  work  had  the  following  objectives  relative 
to  aircraft  onboard  fault  monitoring  and  diagnosis; 

1.  Identify  guidelines  for  automation, 

2.  Identify  crew  interfaces. 

3.  Determine  if  artificial  intelligence  techniques  could  be  used,  and. 

4  Develop  a  prototype  to  demonstrate  the  chosen  approach.  [19,  1] 

The  prototype  system  they  developed  is  called  Faultfinder.  It  includes  fault  monitoring  and 
diagnosis  functions,  and  a  blackboard  structure  to  pass  information  between  the  functions.  The 
fault  monitor  is  based  on  a  numerical  model  of  the  JT8D  turbojet  engine.  The  monitor  can  either 
input  data  from  a  stored  time-ordered  file  of  sensor  readings,  or  it  can  interact  ively  accept  fault 
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symptoms  from  the  operator.  Fault  symptoms  either  computed  or  accepted  by  the  monitor  are 
passed  to  the  diagnosis  system,  which  performs  its  function  in  two  stages. 

Stage  1  of  the  diagnosis  function  performs  fault-symptom  association.  This  is  a  rudimentary 
rule-based  approach  which  matches  the  current  fault  symptoms  with  the  condition  part,  or  left- 
hand  side,  of  a  set  of  rules.  If  a  match  is  found,  the  action  part,  or  right-hand  side,  of  the  matched 
rule  is  reported  as  the  cause  of  the  fault  symptoms.  Stage  1  has  no  chaining  capability,  and  so 
cannot  use  the  rules  to  produce  intermediate  conclusions.  If  a  match  is  not  found  by  Stage  1,  the 
fault  symptoms  are  passed  to  Stage  2. 

Stage  2  uses  the  fault  symptoms  and  model-based  reasoning  to  localize  the  fault  and  produce 
a  fault  hypothesis.  The  model  is  a  semantic  network  representation  of  the  aircraft's  functional  and 
physical  structure.  To  produce  a  valid  fault  hypothesis.  Stage  2  generates  many  interim  hypothe¬ 
ses,  each  of  which  begins  with  the  assumption  that  one  of  the  aircraft’s  primitive  components  is 
responsible  for  all  the  current  fault  symptoms  Each  hypothesis  is  produced  by  building  a  chain 
of  dependency  from  the  primitive  component  through  all  those  components  that  depend  on  i*. 
This  dependency  chain  is  call  a  propagation  path  in  Faultfinder.  The  propagation  path  stops  if 
a)  a  component  is  reached  that  has  no  other  components  depending  on  it.  (usually  the  top  of  the 
component  hierarchy),  or  b)  a  component  is  reached  which  has  a  sensor  associated  with  it  and  the 
sensor  is  not  one  that  is  producing  one  of  the  current  fault  symptoms  A  hypothesis  produced  in 
this  way  is  considered  to  be  valid  if  till  the  current  symptoms  come  from  sensors  that  are  associated 
with  one  of  the  components  on  this  hypothesis’  propagation  path. 

Components  on  the  propagation  path  of  a  valid  hypothesis  are  assigned  different  degrees 
of  fault  severity.  The  primitive  component  at  the  begining  of  the  propagation  path  is  called  the 
RESPONSIBLE-COMPONENT.  Components  whose  associated  sensors  are  producing  the  current 
symptoms  are  called  DEFINITELY-AFFECTED.  Components  which  are  on  the  propagation  path 


but  do  not  have  associated  sensors  are  called  POSSIBLY-AFFEt  TED  These  t ! i r-  •  degrees  ■  >t 


fault  severity  are  presented  to  the  operator  in  a  series  of  graphics  displays  which  show  drawings 
of  the  overall  aircraft  and  its  individual  systems.  On  the  graphics  displays,  the  drawing  of  the 
RESPONSIBLE-COMPONENT  is  shaded  darkest,  and  the  POSSIBLY-AFFECTED  components 
are  shaded  lightest.  These  displays  quickly  show  the  operator  the  direct  and  indirect  effects  of  the 
current  fault  situation. 

The  Faultfinder  system  closely  matches  the  requirements  for  the  NASP  system  status  monitor. 
It  already  has  two  of  the  five  diagnostic  hierarchy  levels,  their  interfaces  are  implemented  through 
a  blackboard,  and  the  semantic  network  knowledge  base  has  the  structure  needed  to  develop  the 
full  functional  hierarchy.  For  these  reasons,  Faultfinder  was  chosen  to  serve  as  the  basis  for  the 
NASP  System  Status  Monitor. 

4.2  SASP  Knowledge  Base 

The  first  task  in  modifying  the  Faultfinder  system  to  become  a  NASP  System  Status  Monitor 
(SSM)  was  to  develop  the  knowledge  base.  This  involved  both  making  the  knowledge  base  specific 
to  the  NASP  domain  and  extending  the  knowledge  base  to  include  all  five  levels  of  the  functional 
hierarchy. 

4-2.1  S’ ASP-specific  Knowledge  Faultfinder's  knowledge  base  originally  contained  represen¬ 
tations  of  only  the  hydraulic  system  and  one  engine.  There  were  functional  and  physical  dependency 
links  within  those  two  systems,  but  neither  of  those  links  existed  between  the  system  and  aircraft 
levels.  The  only  links  that  existed  between  these  levels  showed  that  one  was  a  PART-OF  the  other 

The  NASP  aircraft  description  first  needed  different  system  definitions  than  those  used  in 
Faultfinder.  The  scope  of  this  study  did  not  allow  an  exhaustive  description  of  every  possible 
system  in  an  aircraft  as  complex  as  the  NASP.  Therefore,  a  subset  of  five  primary  systems  was 
chosen  to  represent  the  NASP  aircraft.  These  five  systems  are: 


1.  Propulsion  system,  which  includes  two  engines. 


2.  Hydraulic  system  with  two  independent  subsystems. 

3.  Fuel  system, 

4.  Flight  control  system,  and 

5.  Thermal  protection  system. 


Appendix  A  contains  a  description  of  the  function  and  structure  of  each  of  these  systems. 

After  the  five  aircraft  systems  and  their  components  were  added  to  the  knowledge  hose, 
their  interconnections  were  represented  with  functional  dependency  links.  Here,  the  difference 
between  Faultfinder  and  the  NASP  SSN1  is  that  the  N'ASP  knowledge  base  shows  that  the  aircraft 
is  dependent  on  the  proper  functioning  of  its  constituent  systems,  while  Faultfinder  does  not.  In 
the  NASP  SSM.  inter-level  dependency  extends  from  the  top  of  the  functional  hierarchy  to  the 
bottom.  It  is  this  dependency  between  levels  that  allows  the  NASP  SSM  to  show  how  faults  at  any 
level  of  the  hierarchy  can  affect  any  higher  level. 

4-2.2  Extending  the  Knowledge  Base  The  last  additions  to  the  NASP  SSM  knowledge  base 
were  the  two  highest  levels  of  the  hierarchy:  the  mission  and  flight  phase  levels.  The  structure  of 
these  two  levels  is  somewhat  different  than  the  lower  three  levels.  These  two  levels  have  parts  and 
functional  dependencies  that  are  conceptual  operating  states  rather  than  physical  hardware.  As 
an  example,  the  mission  itself  is  an  extended  operating  state,  and  it  is  dependent  on  the  five  flight 
phases,  which  are  also  operating  states.  In  turn,  each  of  the  flight  phases  is  functionally  dependent 
on  both  physical  (the  aircraft)  and  conceptual  (lift,  drag,  altitude,  etc.)  components. 

One  shortcoming  of  the  structure  of  the  knowledge  base  is  its  inability  to  represent  logical 
relationships.  If  a  component  is  dependent  on  three  other  components,  there  is  no  way  to  say  that 
it  depends  on  all  three  at.  the  same  time  (1  AND  2  AND  3).  or  that  in  some  situations  it  depends 
■  ui  two  components  together  or  a  third  by  itself  ((1  AND  2)  OR  3) 
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The  complete  N'ASP  System  Status  Monitor  Knowledge  Base  is  listed  in  Appendix  B 


4.3  Monitoring  Function 

Faultfinder  offers  two  different  ways  to  perform  the  monitoring  function.  First,  the  user  can 
provide  a  file  of  raw  sensor  readings.  These  data  will  be  read  by  Faultfinder,  and  the  values  will 
be  compared  to  the  sensor  values  predicted  by  the  monitor’s  numerical  models.  If  the  input  data 
disagree  with  the  predicted  sensor  values,  the  monitor  will  produce  fault  symptoms  to  be  used  by 
the  diagnosis  function.  In  the  alternate  method,  the  user  can  interactively  enter  fault  symptoms, 
thus  bypassing  the  numerical  models. 

The  N'ASP  SSM  currently  allows  only  interactive  entry  of  fault  symptoms  The  user  selects 
the  system  where  a  symptom  is  to  appear,  the  sensor  which  will  report  the  symptom,  and  the 
qualitative  value  reported  by  the  sensor.  Figure  7  shows  the  available  systems  in  the  N’ASP  SSM. 
the  sensors  that  each  system  contains,  and  the  values  that  can  be  assigned  to  each  sensor. 

As  Figure  7  indicates,  the  user  is  not  able  to  specific  the  time-variance  of  any  of  the  sensor 
values,  only  the  current  value.  The  addition  of  this  capability  would  allow  the  SSM  to  perform 
temporal  reasoning  tasks,  such  as  prediction  and  planning. 

When  the  NASP  and  its  missions  are  more  clearly  defined,  numerical  models  of  its  systems 
and  operations  can  be  developed  and  added  to  the  NASP  SSM  monitoring  function. 

4-4  Diagnosis  Function 

Both  Faultfinder  and  the  NASP  SSM  perform  a  two-stage  diagnosis  function  and  display 
their  results  in  both  text  and  graphics  form.  However,  there  is  one  important  difference  in  the  way 
the  NASP  SSM  performs  its  second  stage.  This  difference  allows  the  NASP  SSM  to  determine  tie- 


propagation  of  fault  affects  through  the  entire  functional  hierarchy,  not  just  within  a  single  system 
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4-4-1  Stage  1  Both  Faultfinder  and  the  NASP  SSM  use  a  two-stage  fault  diagnosis  process. 
Stage  1  compares  the  current  symptoms  to  a  set  of  stored  fault-symptom  association  rules.  This 
diagnosis  stage  has  the  advantage  of  quickly  recognizing  the  most  common  fault  situations.  If  the 
fault  symptoms  do  not  match  any  of  the  rules  in  Stage  1,  then  Stage  2  of  the  diagnosis  function  is 
engaged. 


4-4-2  Stage  2  To  diagnose  a  fault  situation.  Faultfinder's  Stage  2  produces  a  series  of  diag¬ 
nosis  hypotheses.  Each  hypothesis  consists  of  a  list  of  components  from  the  functional  hierarchy 
of  the  aircraft.  This  list  is  called  the  propagation  path,  and  starts  with  a  unique  primitive  com¬ 
ponent.  Each  hypothesis  is  based  on  the  assumption  that  its  primitive  component  is  responsible 
for  the  current  set  of  fault  symptoms.  This  assumption  is  tested  by  building  a  propagation  path 
from  the  primitive  component  to  each  component  that  is  dependent  on  it  (as  determined  by  the 
"functional-dependents"  links  in  the  semantic  network).  A  propagation  path  is  stopped  in  one 
ot  two  ways.  The  first  and  most  obvious  way  is  if  the  propagation  path  reaches  the  top  of  the 
functional  hierarchy.  The  second  way  is  more  subtle  and  also  more  important.  If  the  propagation 
path  reaches  a  component  that  has  a  sensor  associated  with  it  (as  determined  by  the  ‘‘associated- 
sensor.*  ’  link  in  the  semantic  network),  and  that  sensor  is  not  producing  one  of  the  current  fault 
symptoms,  then  the  propagation  path  stops.  I  his  reason  for  stopping  a  propagation  path  is  tin- 
basis  of  the  diagnosis  process  and  deserves  further  explanation. 

By  assuming  that  a  particular  primitive  component  is  responsible  for  the  current  fault  >itu- 
ation.  the  diagnosis  function  also  assumes  that  the  effects  of  the  faulty  primitive  component  will 
propagate  through  the  functional  hierarchy.  Since  the  diagnosis  function  only  handles  single  faults, 
then  all  current  fault  symptoms  must  be  caused  by  the  propagated  effects  of  the  responsible  com¬ 
ponent.  For  a  fault  to  propagate,  its  effects  must  be  felt  on  the  entire  propagation  path.  Therefore, 
if  a  component  has  a  sensor  which  is  not,  affected  by  the  fault  propagation,  that  component  cannot 


be  on  the  propagation  path 


Figure  8.  Sample  Fault  Propagation  Tree. 


Onre  hypothec’s  are  produced  for  all  the  primitive  components,  they  are  tested  for  validity 
A  hypothesis  is  valid  only  if  it  explains  all  of  the  current  fault  symptoms.  That  is.  the  propagation 
path  of  a  valid  hypothesis  will  contain  all  the  components  whose  sensors  are  producing  the  current 
fault  s> mptoms 

A  simple  example  will  h"!p  to  illustrate  this  process.  Consider  the  graph  in  Figure  s  N..«!e,, 
"A  through  G "  represent  the  components  of  a  system  being  diagnosed,  with  nodes  “E" .  "F "  and 
"G"  representing  primitive  components.  The  nodes  are  connected  by  directed  arcs  which  represent 
functional  dependencies  Thus.  “B”  depends  on  "E",  “C"  depends  on  “F",  "D"  depends  on  ”G" . 
and  “A"  depends  on  “B" .  “C"  and  "D”  There  are  three  sensors  in  this  system:  “X".  “V‘  and  “Z" . 
with  sensors  “Y"  and  "Z  reporting  faults 

The  diagnosis  function  will  attempt  to  build  a  path  from  a  primitive  mp  u-  iit  t hr- gii  all 
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will  begin  with  a  path  from  "E"  to  "B"  Since  the  sensor  associated  with  "B"  is  not  affected,  this 
pall)  cannot  be  completed,  and  this  hypothesis  will  include  only  "F,” 

The  second  hypothesis  will  begin  with  a  path  from  “F"  to  ”C"  Since  there  is  nothing  at 
to  stop  the  propagation,  this  path  will  continue  to  “A”  which  has  an  affected  sensor  and  so  should 
be  included  Therefore,  the  second  hypothesis  is  “F  C~A(X)“ 

I  he  third  hypothesis  will  begin  with  a  path  from  "(l"  to  "D  Node  lias  an  affected  sensor, 
so  it  can  be  included  in  the  propagation  path  The  next  node,  node  “A",  also  has  an  affected  sensor 
and  can  be  included  m  the  path  Therefore,  the  third  hyp  >tliesis  is  "G-D( Y)~A( X )" 

After  all  possible  hypotheses  have  been  produced,  the  diagnosis  function  will  determine  if  any 
of  the  hypotheses  is  valid  The  test  for  validity  will  be  if  the  hypothesis  includes  all  of  the  currently 
alTected  sensors.  Of  the  three  hypotheses  produced  in  this  example,  only  the  third  hypothesis 
includes  both  sensors  "X"  and  "V".  Therefore,  the  third  hypothesis  is  the  only  valid  hypothesis, 
and  it  has  declared  the  primitive  component  at  node  "G“  to  be  responsible  for  the  current  fault 

There  is  one  major  difference  between  Faultfinder's  implementation  of  the  diagnosis  function 
and  the  NASP  SSM's  implementaion.  When  Faultfinder  is  activated,  it  reads  a  file  containing 
the  physical  description  of  the  aircraft.  This  description  is  in  the  form  of  the  semantic  network 
knowledge  base  In  the  knowledge  base,  the  sensors  are  linked  to  the  components  to  which  they  are 
physically  attached.  Faultfinder  modifies  the  knowledge  base  after  it  is  loaded  so  that,  the  sensor 
associations  are  "migrated"  up  the  functional  hierarchy.  I  bis  has  the  affect  of  giving  any  particular 
component  a  list  of  associated  sensors  that  includes  its  own  original  sensors  and  all  sensors  from  its 
constituent  parts.  This  sensor  migration  arrangement  has  some  practical  uses,  such  as  localizing 
the  generation  of  hypotheses  to  only  those  parts  of  the  knowledge  base  that  have  affected  sensors. 
However,  sensor  migration  has  a  detrimental  effect  on  the  form  of  diagnosis  used  in  the  NASP  SSM 

Fault  finder’s  knowledge  base  has  funct  ion  a)  dependency  links  only  within  systems  I  here!  ore. 
fault  effects  can  propagate  only  within  a  system  On  the  oile  r  hand,  the  NASP  SSM’s  functional 
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dependency  links  extend  from  the  bottom  to  the  top  of  the  functional  hierarchy  in  order  to  show 
the  full  effect  of  a  fault  situation.  If  the  NASP  SSM  were  to  use  the  sensor  migration  technique,  the 
component  at  the  top  of  the  functional  hierarchy  would  have  every  sensor  in  the  physical  system 
associated  with  it.  Therefore,  the  top  component  could  be  on  every  propagation  path,  and  far  too 
many  seemingly  valid  hypotheses  would  be  produced.  For  this  reason,  the  NASP  SSM  does  not  use 
sensor  migration,  and  so  does  not  localize  its  hypothesis  generation.  What  the  NASP  SSM  loses  in 
efficiency  is  gamed  in  its  ability  to  show  the  full  effects  of  a  fault  situation. 

Doth  Faultfinder  and  the  NASP  SSM  produce  a  default  hypothesis  if  a  valid  hypothesis 
cannot  be  generated  A  default  hypothesis  will  consist  of  two  or  more  separate,  unconnected  fault 
propagation  paths.  Each  of  these  default  paths  will  begin  with  a  component  with  an  affected  sensor. 
This  component  is  not  necessarily  a  primitive  component.  The  default  paths  will  propagate  from 
these  components  until  stopping  for  one  of  the  reasons  stated  above. 

If  all  the  primitive  components  failed  to  produce  a  valid  hypothesis,  an  alternative  to  produc¬ 
ing  a  default  hypothesis  would  be  to  attempt  to  build  hypotheses  based  on  composite  components. 
This  would  allow  Stage  2  to  narrow  the  diagnosis  to  a  subsystem  or  system  rather  than  a  primitive 
component  This  capability  should  be  explored  as  an  enhancement  to  the  NASP  SSM. 

Whether  it  produces  valid  or  default  hypotheses,  the  diagnosis  function  displays  it  results 
both  as  text  and  graphics.  The  diagnosis  graphics  displays  will  be  examined  next. 

4-4-J  Diagnosis  Displays  Figure  9  shows  the  NASP  SSM  system  display  The  system  dis¬ 
play  is  divided  into  four  windows,  or  panes,  where  different  information  is  presented  Monitor 
information  is  displayed  in  the  upper  right  and  lower  left  panes.  The  upper  right  pane  shows  a 
graphical  representation  of  engine  instruments  The  instrument  readings  change  with  changes  in 
input  sensor  data.  A  future  enhancement  to  the  NASP  SSM  would  have  instrument  displays  tor 
the  other  aircraft  systems  displayed  in  this  pane  at  appropriate  times.  The  current  fault  symptoms 
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Results  of  the  diagnosis  function  occupy  the  upper  left  and  lower  right  display  panes.  After 
the  diagnosis  function  has  produced  a  valid  or  default  hypothesis,  its  results  are  displayed  in  two 
ways.  First,  the  hypothesis  is  listed  in  textual  form  in  the  lower  right  display  pane,  called  the 
diagnosis  pane.  The  diagnosis  pane  is  too  small  to  display  the  entirety  of  most  hypotheses,  so  the 
display  is  scrolled  one  pane  at  a  time.  Figure  10  shows  an  example  of  the  entire  listing  of  a  fault 
hypothesis.  The  first  line  of  the  hypothesis  listing  shows  which  hypothesis  is  being  listed  if  there  are 
more  than  one.  The  next  section,  labeled  “Causes.”  showns  the  results  of  Stage  1  of  the  diagnosis 
function.  If  no  Stage  1  Diagnosis  has  been  produced,  the  cause  will  be  listed  as  “Unknown.” 
Next,  each  affected  component  in  the  fault  propagation  path  is  listed  along  with  the  component's 
fault  severity.  Fault  severities  fall  into  three  categories.  A  “RESPONSIBLE-COMPONENT"  is 
i he  component  judged  to  be  responsible  for  all  the  current  fault  symptoms.  A  “DEFINITELY- 
AFFE1CTED”  component  is  one  that  is  directly  on  the  fault  propagation  path,  or  one  that  has 
an  alfected  sensor  A  “POSSIBLY- AFFECTED”  component  is  one  that  is  on  a  branch  of  the 
propagation  path  and  has  no  sensors  associated  with  it.  The  next  section  in  the  hypothesis  listing 
is  the  type  of  reasoning  used  to  arrive  at  the  current  hypothesis.  The  possible  types  are  “SINGLE 
FAULT  FUNCTIONAL  PROPAGATION”  and  "SINGLE  FAULT  PHYSICAL  PROPAGATION  ” 
Ihe  NASH  SSM  only  supports  functional  propagation.  Finally,  the  fault  propagation  path  is  listed. 
This  is  the  same  as  the  affected  components  listing,  but  fault  severities  are  not  included. 

The  results  of  a  fault  hypothesis  are  also  displayed  graphically  in  the  upper  right  portion  of 
the  display,  called  the  system  window.  There  are  lt>  different  displays  that  can  be  shown  in  the 
system  window.  These  displays  can  be  grouped  into  the  five  levels  of  the  functional  hierarchy,  as 
shown  in  Figure  11  Each  display  depicts  components  of  its  corresponding  level  of  the  functional 
hierarchy.  When  a  fault  hypothesis  determines  that  a  component  is  affected  by  the  current  fault 
situation,  the  outline  of  that  component  will  be  shaded,  using  the  key  at  the  bottom  of  the  system 
window.  The  shading  corresponds  to  the  fault  severity  for  that  component  I  Ins  shading  scheme 
■  1 1 1 1 < - k  1  y  shows  the  flight  crew  those  components  affected  by  a  fault  situation.  Figures  111  through  -7 
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Hypothesis  1  of  2 


Causes 

UNKNOWN 

Affected  Components 

( "GEARBOXA"  "RESPONSIBLE-COMPONENT" ) 

( "GEARBOXA"  " DE F I N I TELYAF FECTED " ) 

(  "  ENGINE-HYD-PUMPAi  '*  "  D E F I N I TELYAFFECTED  "  ) 

( "HYDRAULIC-LINEA"  "DEFINITELYAFFECTED" ) 

( " HYDRAULIC- SUBS YSTEMA”  “DEFINITELYAFFECTED" ) 

(  " H YDRAUL I C-S YSTEMA"  "DEFINITELYAFFECTED" ) 

( "TAKEOFF-PLANE"  "DEFINITELYAFFECTED" ) 

( "TAKEOFF"  "DEFINITELYAFFECTED” ) 

( "MISSIONA"  "POSSIBLYAFFECTED" ) 

( "CLIMB"  "DEFINITELYAFFECTED" ) 

( "CLIMB-PLANE"  " POSS I BLYAFFECTED" ) 

( "CRUISE-PLANE"  "POSSIBLYAFFECTED" ) 

( "DESCENT- PLANE"  "POSSIBLYAFFECTED" ) 

( "LANDING-PLANE"  "POSSIBLYAFFECTED" ) 

( "HYD-SUBSYSA-PRESSURE"  "DEFINITELYAFFECTED" ) 

( " LEFT- E LEVON- ACTUATOR- 1 ”  "DEFINITELYAFFECTED" ) 
( " R I GHT-E LEVON- ACTUATOR- 1 ”  "POSSIBLYAFFECTED" ) 

( "BODY- FLAP-ACTUATOR- 1"  "POSSIBLYAFFECTED" ) 

( "RUDDER-ACTUATOR-1"  "POSSIBLYAFFECTED" ) 


Fault  Type 

Single-Fault- Functional -Propagation 

Propagation  Path 
( "GEARBOXA" ) 

( " ENG INE-HYD-PUMPAl " ) 

( "HYDRAULIC-LINEA" ) 

( "HYDRAULIC- SUBS YSTEMA" ) 

(  "HYDRAULI C-S  YSTEMA " ) 

( "TAKEOFF-PLANE" ) 

( "TAKEOFF" ) 

( "MISSIONA" ) 

(  "CLIMB"  ) 

( "CLIMB-PLANE" ) 

( "CRUISE-PLANE" ) 

( "DESCENT-PLANE" ) 

( "LANDING- PLANE" ) 

( "HYD-SUBSYSA-PRESSURE" ) 

( " LE FT- ELE VON- ACTUATOR- 1 " ) 

( "RIGHT-ELEVON-ACTUATOR-1” ) 

( "BODY- FLAP -ACTUATOR- 1" ) 

( " RUDDER -ACTUATOR- 1 " ) 


10  S.unj’l'-  I  uilt  Hypothesis  Listing 
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Figure  12.  Mission  Display. 


show  o.icii  of  ' he  1(J  possible  displays  m  the  system  window. 


4-5  Remediation  Function 

The  remediation  function  is  intended  to  propose  a  course  of  action  to  the  flight  crew  that  will 
counteract  the  effects  of  the  current  fault  symptoms.  As  was  explained  in  the  previous  chapter,  it 
was  decided  that  the  remediation  function  would  seek  to  compensate  for  the  effects  of  the  highest- 
level  fault  symptom.  The  highest- level  fault  symptom  is  defined  as  the  symptom  whose  associated 
component  is  highest  in  the  functional  hierarchy  The  remediation  function  will  attempt  to  produce 
one  or  more  remedies  for  each  valid  hypothesis. 

After  the  diagnosis  function  has  produced  a  set  of  valid  hypotheses,  the  remediatra  function 
seeks  the  highest-level  fault  symptom.  It  st  arts  at  the  top  of  the  functional  hierarchy  and  -earches 


downward  until  it  finds  a  component  whose  associated  sensor  is  producing  oie-  of  the  current  fault 


FUEL 

SYSTEM 


symptoms  If  the  associated  sensor  has  a  ''causes'  link  m  rh<*  knowledge  base,  the  remediation 
function  lucks  fur  a  "causes'  link  whose  result  will  counteract  the  symptom  that  the  sensor  is 
report  in;  IV. r  ''\"nr.|  !.  .  if  r  he  symptom  is  "Airspeed  Low" .  tli.  n  the  remediation  function  will  !■  ok 
for  a  "causes'  link  that  says  "<some  action>  causes  Increase  Airspeed" 

Once  tin-  highest-level  fault  symptom  and  an  appropriate  counter-action  are  found,  tic  reme¬ 
diation  function  will  work  backwards  from  the  "action"  part  of  the  “causes  "  link  until  it  finds  tic 
most  elementary  action  that  will  eventually  produce  the  desired  counter-action  to  the  huhe.-i -level 
fault  symptom.  This  process  is  repeated  for  all  unique  sequences  of  actions  that  will  produce  'Im 
same  fault  symptom  counter-action. 

Next,  the  group  of  action  sequences  must  be  pruned.  This  is  done  by  keeping  only  tlc.se 
.vt ion  sequences  that  counteract  the  greatest  number  of  fault  symptoms  F< >r  example,  assume 
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urrr-.'it  fault  symp-t  'ins. 


1  Airspeed  Low¬ 
'd.  1-  iiel-  Pressure  Low 
d.  Lhrust  Low 

and  there  are  two  competing  remedial  action  sequences, 

1.  Engage  Afterburner  causes  Increase  Thrust, 

2  Increase  Thrust  causes  Increase  Airspeed 


and, 

1.  Decrease  Weight  causes  Decrease  Drag. 

2.  Decrease  Drag  causes  Increase  Airspeed. 

In  this  case,  the  first  action  sequence  would  be  preferred,  because  it  counteracts  two  of  the  three 
current  symptoms,  whereas  the  second  action  sequence  only  counteracts  the  “Airspeed  Low”  symp¬ 
tom. 

Remedies  are  displayed  in  textual  form  on  the  diagnosis  pane  of  the  display.  Figure  28  shows 
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an  example  remedy  listing. 
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V.  Results 


To  demonstrate  its  functions  and  capabilities,  the  NASP  System  Status  Monitor  was  presented 
with  three  different  types  of  test  inputs.  The  first  series  of  tests  involved  a  set  of  four  logically 
related  fault  symptoms.  These  symptoms  were  entered  interactively  into  the  SSM  five  times  On 
the  first  trial,  all  four  symptoms  were  entered.  For  the  second  through  fifth  trials,  a  dilf-rent  one 
of  the  four  symptoms  was  omitted. 

i'he  second  series  of  test  inputs  also  included  a  set  of  four  logically  related  fault  symptoms. 
Again,  these  symptoms  were  entered  five  times,  with  all  four  symptoms  entered  on  the  first  trial. 
For  the  second  through  fifth  trail,  a  single  additional  symptom  was  added  to  the  other  four. 

The  results  of  the  test  runs  show  that  the  NASP  SSM  will  successfully  diagnose  sets  of 
logically  related  fault  symptoms,  using  both  fault  association  rules  and  functional  relationship 
fault  hypothesis  generation.  However,  if  the  symptoms  are  somehow  discontinuous,  or  random  and 
unrelated,  the  best  the  SSM  can  do  is  to  produce  a  default  hypothesis. 

1  Test  1A 

The  first  set  of  fault  symptoms  used  to  test  the  performance  of  the  NASP  System  Status 
Monitor  included  logically  related  faults.  The  intent  was  that  a  fault  in  one  of  the  hydraulics  sub¬ 
systems  would  affect  the  flight  control  system,  with  the  flight  control  anomaly  ultimately  impairing 
overall  aircraft  performance.  The  following  four  fault  symptoms  were  given  to  the  SSM  to  perform 
this  test; 

1.  Hvd-SubsvsA-Pressure  -  Low 

2.  Hyd-PumpA  1-Pressure  -  Low 

3.  Left-Elevon-Position  -  Low 

■1  <  'limb-  Kate  A  -  Low 
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When  presented  with  these  four  faults,  the  SSM  did  not  produce  a  Stage  !  diagnosis.  but 
returned  two  Stage  2  hypotheses.  Both  of  these  hypotheses  contained  two  remedies. 

Figure  29  is  a  diagram  of  the  fault  propagation  path  produced  by  the  SSM  for  the  !ir>t 
Stage  2  hypothesis.  In  this  hypothesis,  the  gearbox  in  the  left  engine  is  the  responsible  conpoin  iit. 
and  the  fault  effects  propagate  directly  to  the  mission  level  at  the  top  of  the  functional  hierarchy. 
The  legend  at  the  bottom  of  Figure  29  shows  which  components  in  the  diagram  are  responsible 
components,  definitely  affected,  possibly  affected,  or  sensors. 

One  interesting  aspect  of  this  hypothesis  is  its  apparent  deviation  from  the  intent  of  its  test 
set  of  fault  symptoms.  The  fault  propagation  was  intended  to  begin  with  a  fault  in  or  near  the  left 
engine-driven  hydraulic  pump  (Engine-Hyd-PumpA).  This  fault  was  supposed  to  propagate  through 
the  left  hydraulic  subsystem  to  the  flight  control  system,  where  it  would  affect  the  hydraulically- 
driven  control  surface  actuators.  The  affected  actuators  would  incorrectly  position  a  control  surface 
which  would  aerodynamically  impair  the  climb  rate.  Figure  29  appears  to  show  that  the  fault 
propagation  within  the  flight  control  system  actually  has  no  effect  on  the  upward  propagation  of 
the  fault  in  the  functional  hierarchy.  This  is  true  to  a  point,  since  the  propagation  path  just  as 
easily  could  have  gone  from  "Flight-Control-SysA"  to  “Takeoff- Plane”  as  it  did  from  “Hydraulic- 
System  A”  to  “Takeoff-Plane."  The  Takeoff-Plane  (and  all  other  instances  of  the  "Plane")  are 
functionally  dependent  on  both  the  Flight  Control  System  and  the  Hydraulic  System.  The  reason 
one  path  was  chosen  over  the  other  lies  in  the  knowledge  base.  The  "functional-dependents"  links 
for  the  “Hydraulic-LineA"  are  ordered  unintentionally  so  that  the  "Hydraulic-SubsystemA"  conn's 
before  the  “Left-Elevon-Actuator-1.”  Therefore,  the  propagation  path  through  the  hydraulic  system 
is  explored  (and  found  to  lead  to  the  top  of  the  functional  hierarchy)  before  the  path  through  the 
Flight  Control  System  is  attempted. 

The  second  hypothesis  for  this  set  of  fault,  symptoms  is  the  same  as  the  first  except  that  the 
left  engine-driven  hydraulic  pump  is  now  the  responsible  component  (see  Figure  HO).  Since  tin- 
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''Left-Elevon-Position”  symptom  has  a  drastic  effect  on  the  suggested  remedial  actions 


Figure  32  shows  the  fault  propagation  path  for  Test  IB.  This  diagram  is  the  same  as  for 
Test  1A.  except  that  the  fault  effects  for  the  entire  Flight  Control  System  are  omitted  In  this 
test  case,  the  beginning  and  end  of  the  propagation  path  are  established  by  the  "Hyd-PumpA  1- 
Pressure”  and  “Climb-RateA”  symptoms,  respectively.  The  three  components  in  the  center  of  the 
propagation  path  (Hydraulic-SubsystemA,  Hydraulic-SvstemA.  and  Takeoff- Plane)  do  not  have 
associated  sensors,  and  so  just  carry  the  propagation.  They  do  not  have  the  potential  to  stop  the 
propagation 

Let  us  assume  that  either  the  Hydraulic-SubsystemA  or  Hydraulic-SvstemA  had  their  own 
sensors,  and  those  sensors  were  unaffected  by  the  current  symptoms.  In  this  case,  they  could  stop 
the  fault  propagation  and  Stage  2  would  be  forced  to  seek  another  path,  such  as  through  the  Flight 
Control  System.  Under  this  assumption,  Test  1  would  still  produce  the  same  basic  hypotheses, 
with  the  propagation  path  going  from  the  “Flight-Control-SysA”  rather  than  from  the  “Hydraulic- 
SystemA”  to  the  “Takeoff-Plane.”  The  same  could  not  be  said  for  the  hypotheses  produced  in 
Test  IB.  Here  the  hydraulic  subsystem  symptoms  would  be  cut  off  from  the  higher  level  symptom, 
forming  two  “islands”  of  symptoms  and  their  effects  These  “islands”  are  in  fact  how  a  default 
hypothesis  is  represented  when  no  valid  hypothesis  can  be  generated. 

The  major  difference  between  Test  1A  and  Test  IB  is  in  the  generation  of  remedial  actions. 
The  two  Test  1A  hypotheses  each  had  two  remedies,  and  each  remedy  counteracted  two  symptoms 
(Climb-RateA  and  Left-Flevon-Position).  Since  “Left-Elevon-Position”  is  no  longer  a  symptom,  it 
cannot  affect  the  choice  of  remedial  actions.  In  Test.  IB.  the  best  remedies  to  be  found  counteract 
only  one  symptom,  and  there  are  22  such  remedies,  shown  in  Figure  33. 

Clearly,  this  is  a  case  where  some  other  criteria  must  be  used  to  select  a  smaller  number  "1 
appropriate  remedies 
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■5.  <  Test  1 C 


This  test  was  the  same  as  Test  1A  except  that  the  "Climb-RateA"  symptom  was  <i*Tf-t »-■  1 . 
Ilus  deletion  changed  the  entire  outcome  of  t lie  diagnosis  process,  since  no  valid  hypothesis  could 
he  generated.  The  result  is  a  default  hypothesis,  where  each  sensor  is  declare  to  he  "definitely 
affected"  and  all  components  on  what  would  otherwise  be  called  the  propagation  path  are  declared 
to  be  “possibly  affected."  Because  the  affected  components  cannot  be  connected  to  form  a  single 
propagation  path,  the  default  hypothesis  has  “islands”  of  fault  effects  which  can  be  seen  in  Figure  .'id . 


Since  Stage  2  of  the  diagnosis  function  did  not  produce  a  valid  fault  hypothesis,  the  remedia¬ 
tion  function  did  not  produce  any  remedies.  Although  the  current  implementation  of  the  SSM  will 
not  attempt  to  produce  remedies  unless  there  is  at  least  one  valid  hypothesis,  there  is  no  conceptual 
prohibition  to  doing  so.  The  assumed  intent  of  the  remediation  function  was  to  counteract  the  ef¬ 
fects  of  as  many  fault  symptoms  as  possible  without  regard  for  the  cause  of  those  symptoms.  1'uder 
that  assumption,  the  absence  of  a  diagnosis  hypothesis  should  not  preclude  an  attempt  to  coun¬ 
teract  the  fault  symptoms.  Therefore,  the  remediation  should  perhaps  be  modified  to  recommend 
remedial  action  in  all  cases. 

This  test  shows  that  the  deletion  of  a  single  symptom  can  prevent  the  generation  of  a  valid 
hypothesis.  If  Stage  2  could  recognize  the  absence  of  a  key  symptom,  it  may  be  able-  to  compensate 
and  produce  a  valid  hypothesis 

5.4  Test  ID 

This  test  was  tfie  same  as  Test  IA  except  that  the  "Climb-RateA"  symptom  w.as  de|.i,-d 
This  deletion  prevented  Stage  2  of  the  diagnosis  function  from  predicting  any  po»\|,l,  effect  ,,f  :  | . 
fault  situation  <>n  the  highest  level  of  the  functional  hierarchy  I  he  remainder  f  th*  dtagi:-  •*!»  i- 
tic  -  tine  as  "I»*st  l.\.  as  can  he  seen  in  diagram  in  f  igure 
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F i t;ii r»f  3b  lost  ID  Remedy. 

The  deletion  of  the  "Ciimb-RateA "  symptom  also  had  an  effect  on  the  remedies  associated 
with  this  diagnosis.  The  remediation  function  attempts  to  counteract  the  effects  of  the  highest- 
h-vel  fault  symptom.  In  ill  the  previous  test  cases,  the  low  “Climb- Rato  A"  was  the  higi.est-!e\<-i 
symptom.  Since  it  is  not  present  in  this  test,  the  remediation  function  chose  the  next  highest 
-vmptom.  the  low  "Left- Flevon-Posit  ion."  For  both  hypotheses  in  this  test  case,  the  same  reiu-  di  u 
a.  ',;,  n  sequence  was  prescribed.  The  recommended  remedy  for  this  test  is  shown  in  Future  ;}•: 
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Tins  test  was  the  same  as  Test  1A  except  that  the  "IF.  1  Pump  A  1- Pressure"  symptom  was 
d-  J.  This  change  had  the  effect  of  removing  what  was  tie*  f'-ittiniti;  of  the  fault  pr  pa  cat :•  i. 
p  it  h  in  the  pr-vious  test  cases,  as  shown  m  Figure  37  I  in-  set  ..  •  mpt  uns  st  ;.l  pro  !;:  •  1  a  va.  1 
h;.t  diesis  because  1 1  > draahe- LineA  '  is  a!.>-  a  primitive  n-r.'  ind  ••an  t!;eref.,r *!.e 
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5. 6  Test  t?.4 


Test  2 A  involved  another  set  of  fault  symptoms  that  were  logically  related  and  therefore 
should  have  produced  a  valid  fault  hypothesis.  This  set  of  symptoms  was  intended  to  show  the 
propagation  of  a  fault  in  the  fuel  system  to  one  of  the  engines,  arid  the  effect  of  the  engine  problem 
manifesting  itself  in  a  low  Mach  number.  The  set  of  fault  symptoms  for  this  test  were: 

1.  Mach  A  -  low 

2.  ThrustB  -  low 

3.  Fuel-FIowB  -  high 

4.  Feed-TankB-Quantity  -  low. 

As  in  Test  1A,  the  fault  symptoms  in  Test  2A  did  not  produce  a  Stage  1  diagnosis,  but  they 
did  produce  three  Stage  2  diagnoses.  These  diagnoses  are  shown  in  the  fault  propagation  diagrams 
of  Figures  38,  39,  and  40. 

The  fault  propagation  diagram  in  Figure  38  shows  that  the  fault  symptoms  for  this  test 
did  produce  the  intended  propagation  path.  The  only  difference  in  the  three  hypotheses  is  the 
responsible  component.  The  "EngineB-Feed-Tank”  is  the  lowest-level  component  that  must  be 
in  the'  propagation  path,  because  it  is  the  lowest-level  component  with  an  affected  sensor.  The 
"F,ngineB-Feed-Tank"  is  functionally  dependent  on  both  the  “Fwd-Tank-Transfer-Pump"  and  the 
"Alt-Tank-Transfer-Pump."  Neither  of  these  components  have  associated  sensors,  so  they  can  also 
be  considered  responsible  components  in  the  second  and  third  hypotheses. 

For  this  set  of  fault  symptoms.  Stage  2  produces  the  same  single  remedy  for  each  of  the  three 
hypotheses.  This  remedy  attempts  to  counteract  the  highest-level  fault  symptom,  low  "MachA." 
The  remedy,  shown  in  Figure  11.  actually  counteracts  two  other  fault  symptoms  in  addition  to 
"MachA  " 
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Figure  41  Test  2A  Remedy. 


5.7  Test  2D 


This  test  is  the  same  as  Test  2A  except  that  an  additional  symptom,  low  "Fwd-Tunk- 
Quantity,”  is  included.  The  addition  of  this  symptom  at  the  bottom  of  the  fault  propagation  path 
focuses  the  diagnosis  process.  The  result  is  a  single  fault  hypothesis  with  the  “Fwd- Fuel- Tank”  as 
the  responsible  component.  The  remainder  of  the  fault  propagation  path,  shown  in  Future  12.  is 
the  same  as  in  Test  2A. 

In  this  case,  the  additional  symptom  does  not  have  an  effect  on  the  remedial  action  function. 
1  he  same  remedy  is  produced  for  the  single  T-st  2D  hypothesis  as  was  produced  for  each  of  tin- 
Test  2A  hypotheses. 


5. 3  Test  CC 


This  test  is  the  same  as  Test  2A  except  that  an  additional  symptom,  low  ‘‘NIB."  is  included. 
Because  two  of  the  current  symptoms  (high  “Fuel-FlowB”  and  low  "N  1  B” )  matched  one  of  the  ruh-s 
in  the  Stage  1  knowledge  base,  this  set  of  symptoms  produced  a  Stage  1  diagnosis.  The  diagnosis 
of  "Fuel-LeakB”  is  shown  in  Figure  43.  Since  there  are  three  remaining  symptoms  riot  'explained 
by  the  Stage-  2  diagnosis.  Stage  2  also  attempted  to  produce  a  diagnosis. 
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CURRENT- SYMPTOMS 


("MACHA"  49602  NIL  "low"  NIL  NIL  NIL) 

( " THRUSTB "  49606  NIL  "low"  NIL  NIL  NIL) 

(  "FUEL-FLOWB"  49615  NIL  "high"  NIL  NIL  NIL) 

( " FEED-TANKB-QUANTITY"  49621  NIL  "low"  NIL  NIL  NIL) 
("NIB"  49627  NIL  "low"  NIL  NIL  NIL) 
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(  " FUEL-DUMP-VALVEA"  " POSS I B LYAF FECTED "  ) 

(  "  FUEL-DUMP- VALVEB"  " POSSIBLYAFFECTED" ) 

( " FUEL-FLOWB"  "DEFINITELYAFFECTED" ) 

(  " FUEL- L INEB "  "  POSS I B L YAFFECTED " ) 

(  "GAS-GENERATORB"  "POSSIBLYAFFECTED" ) 

( "FUEL-INJECTORB"  "POSSIBLYAFFECTED" ) 

( "THRUSTB"  "DEFINITELYAFFECTED" ) 

( "ENGINEB"  "POSSIBLYAFFECTED" ) 

(  "PROPULSION-SYSTEMA"  "POSSIBLYAFFECTED"  ) 

(  "TAKEOFF-PLANE"  "POSSIBLYAFFECTED" ) 

(  "CLIMB-PLANE"  "POSSIBLYAFFECTED" ) 

(  "CRUISE-PLANE"  "POSSIBLYAFFECTED"  ) 

(  "DESCENT-PLANE"  "POSSIBLYAFFECTED" ) 

(  " LANDING-PL  LNE "  "POSSIBLYAFFECTED" ) 

( "TOTAL-THRUST"  "POSSIBLYAFFECTED" ) 

( "MACHA"  "DEFINITELYAFFECTED" ) 

("CLIMB"  "POSSIBLYAFFECTED") 

(  "MISSIONA"  "POSSIBLYAFFECTED" ) 

( "CRUISE"  "POSSIBLYAFFECTED" ) 

( "MISSIONA"  "POSSIBLYAFFECTED" ) 

( "DESCENT"  "POSSIBLYAFFECTED" ) 

(  "MISSIONA"  "POSSIBLYAFFECTED"  ) 


5.9  Test  2D 


This  test  is  the  same  as  Test  2A  except  that  an  additional  symptom  'ow  "Fwd-Elec-Cooling- 
Pressure."  is  included.  This  test  also  produces  the  same  three  basic  hypotheses  as  Test  2A  (see 
Figures  14 .  45.  and  46). 

However,  the  figures  show  that  the  new  symptom  also  causes  the  fault  to  begin  to  propagate 
into  a  different  aircraft  system,  the  Thermal  Protection  System. 

The  addition  of  the  “Fwd-Elec-Cooling-Pressure”  symptom  does  not  alter  the  remedial  action 
originally  recommended  in  Test  2A.  This  tends  to  confirm  the  intuitive  feeling  that  remedial  actions 
taken  in  the  Thermal  Protection  System  would  not  have  a  direct  effect  on  increasing  Mach  number 

■5. 10  Test  2E 

This  test  is  the  same  as  Test  2 A  except  that  an  additional  symptom,  low  “Right- Elevon- 
Position."  is  included.  However,  the  addition  of  this  symptom  prevents  Stage  2  from  producing  a 
valid  fault  hypothesis.  Only  a  default  hypothesis  is  produced.  The  reason  for  no  valid  hypothesis 
being  produced  can  be  seen  in  the  fault  propagation  path  diagram  in  Figure  47.  The  two  halves  of 
the  propagation  path  lead  to  the  same  components  at  the  top  of  the  functional  hierarchy.  However, 
no  single  path  can  be  drawn  from  either  half  so  that  all  five  fault  symptoms  are  traversed. 

Since  this  is  a  default  hypothesis,  no  remedial  actions  were  recommended.  As  was  the  case 
with  Test  1C,  perhaps  a  remedial  action  for  this  test  case  would  be  just  as  appropriate  and  helpful 
as  in  a  situation  where  a  valid  fault  hypothesis  was  produced. 

This  test  is  the  opposite  of  Test  1C.  where  the  absence  of  a  key  symptom  prevented  generation 
of  a  valid  hypothesis.  Here,  the  presence  of  an  extraneous  symptom  caused  a  default  hypothesis. 
If  Stage  2  could  recognize  the  presence  of  the  irrelevant  symptom.  Stage  2  may  be  able  to  ignore  it 
and  produce  a  valid  hypothesis. 


Possibly— 
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I  I.  Conclusions  and  Rccornmt  ndations 


6.1  Conclusions 

Based  on  the  theoretical  development  and  implementation  of  the  prototype  National  Aero¬ 
space  Plane  System  Status  Monitor,  the  following  general  conclusions  are  drawn 

1.  It  is  useful  to  represent  the  diagnostic  process  as  a  hierarchy  of  functions,  each  operating 
upon  and  building  upon  the  output  of  the  lower  levels  of  the  hierarchy. 

2.  A  combination  of  traditional  expert  system  techniques  and  deeper  functional  reasoning  can 
lead  to  a  more  flexible  diagnosis  system  than  would  be  expected  if  either  technique  were  used 
alone. 

3.  A  systematic  hierarchical  representation  of  a  physical  system  and  its  functions  can  aid  in  both 
acquiring  system  knowledge  and  in  the  development  of  an  effective  diagnostic  process. 

1.  The  hierarchical  functional  representation  of  the  NASP  allows  the  SSM  to  both  diagnose  the 
causes  of  fault  symptoms  and  determine  their  effect  on  all  functional  levels  of  the  aircraft  and 
its  mission. 

One  specific  conclusion  can  also  be  drawn  from  this  study  of  a  prototype  National  Aerospace 
Plane  System  Status  Monitor. 

1.  The  absence  of  one  key  symptom,  or  the  addition  of  one  extraneous  symptom,  can  prevent 
both  Stages  1  and  2  from  producing  a  valid  fault  hypothesis.  (Also  see  Specific  Recommen¬ 
dation  1.) 

6.2  Recommendations 

Based  on  the  results  of  this  study  and  the  capabilities  of  the  prototype  NASP  System  Status 
Monitor,  the  following  general  recommendations  are  made: 

So 


1.  The  SSM  should  be  expanded  to  implement  the  numerical  modeling  capabilities  of  the  moni¬ 
toring  function.  This  capability  would  allow  the  SSM  to  be  operated  with  a  stream  of  sensor 
input  values  to  produce  an  event-driven  simulation  of  a  NASP  mission. 

2.  As  a  project  for  a  future  student  or  group  of  students,  the  two  highest  levels  of  the  diagnosis 
process,  prediction  and  planning,  should  be  added  to  the  SSM. 

3.  The  SSM  displays  and  other  aircrew  interfaces  should  be  subjected  to  a  human  factors  anal¬ 
ysis.  This  analysis  would  determine  the  best  way  to  present  the  SSM  information  to  the 
aircrew,  and  how  best  to  receive  commands  and  information  from  the  aircrew. 

Based  on  the  details  of  the  prototype  NASP  System  Status  Monitor,  the  following  specific 
recommendations  are  made: 

1 .  Both  Stage  1  and  Stage  2  of  the  diagnosis  function  should  be  modified  to  recognize  extraneous 
symptoms,  or  the  absence  of  key  symptoms.  This  would  allow  generation  of  a  valid  hypothesis 
or  diagnosis  in  cases  that  would  otherwise  produce  default  hypotheses. 

2.  The  SSM's  knowledge  base  needs  the  ability  to  represent  logical  relationships.  For  example, 
it  should  be  possible  to  represent  and  reason  about  the  fact  that  the  hydraulic  subsystem 
pressure  is  functionally  dependent  on  pump-A  and/or  pump-B. 

3.  The  capability  should  be  added  to  interactively  enter  or  automatically  infer  the  first  derivative 
of  sensor  values.  As  an  example,  the  user  can  now  specify  a  symptom  such  as  high  or  low 
"Nosecap-Temp.”  The  user  should  also  be  able  to  specific  that  “Nosecap-Temp''  is  moren>mc 
or  decreasing.  Each  of  the  diagnosis  functions  should  also  be  able  to  reason  about  i  le-so  - 
derivative  values. 

4.  Stage  2  of  the  SSM  diagnosis  function  can  build  fault  hypotheses  based  "id. 
primitive  components.  If  no  valid  hypotheses  can  be  produced  si  ; r * 1 1 ■  _ 
ponents.  Stage  2  should  be  able  to  move  up  one  level  ; n  tfi.  *  r  • 


W-MN  Ml  II  SVSTEH  STATUS  NON  I  TO*  FOR  THE  NATIONAL  AEROSFACE  2/ 

FUWECU)  AIR  FORCE  INST  OF  TECH  MRIGHT-PATTERSON  AFI  OH 
SCHOOL  OF  ENGINEER  I  NO  J  H  BAUHANN  DEC  07 
UNCLASSIFIED  AFIT/0CE/ENG/87D-1  F/Q  1/3. 12  NL 


the  diagnosis  process  over  again.  This  would  ensure  that  higher-level  fault  symptoms  were 
diagnosed  at  least  to  the  subsystem  or  system  level. 

5.  Currently,  the  SSM  shows  only  engine  instruments  in  the  upper  right  portion  of  the  display. 
The  interface  functions  should  be  expanded  to  show  instrument  displays  appropriate  to  the 
pictorial  display  in  the  upper  left  portion  of  the  SSM  display.  An  example  would  be  to  display 
fuel  gauges  when  the  fuel  system  is  pictured  in  the  upper  left  display  window. 
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Appendix  A.  Explanation  of  the  NASP  Aircraft  Systems 


The  current  representation  of  the  National  Aerospace  Plane  in  the  NASP  System  Status 
Monitor  knowledge  base  contains  five  aircraft  systems.  These  systems  are 


1.  Propulsion  system 


2.  Hydraulic  system 


3.  Fuel  system 


4.  Flight  controls  system 


5.  Thermal  protection  system. 


Following  is  an  explanation  of  the  physical  properties  of  the  five  aircraft  systems  represented  in  the 
knowledge  base. 


A.  1  Propulsion  System 

The  propulsion  system  consists  of  two  engines.  The  engines  are  modeled  after  the  airturbo 
ramjet  (ATR)  as  described  in  [21].  This  engine  uses  a  gas  generator  supplied  with  cryogenic  fuel 
such  as  liquid  hydrogen/liquid  oxygen.  The  fuel  combines  in  the  gas  generator  and  expands  through 
the  turbine  to  power  the  compressor.  Unburned  fuel  is  combined  in  the  combustor  with  compressed 
air  from  the  compressor.  The  compressor  is  only  needed  at  low  Mach  numbers  (less  than  Mach 
2-3).  At  higher  Mach  numbers,  ram-air  is  sufficient  to  support  combustion  in  the  combustor.  Extra 
hydrogen  fuel  is  added  in  the  combustor  by  the  fuel  injectors.  The  hot  fuel  exhaust  is  expanded 
out  the  nozzle  to  produce  thrust. 

Through  the  gearbox,  each  engine  drives  a  hydraulic  pump  and  an  electric  generator.  The 
“NT”  sensor  measures  the  rotational  speed  of  the  compressor.  The  “EGT”  sensor  measures  the  gas 
temperature  at  the  inlet  to  the  turbine.  The  “EPR"  sensor  measures  the  pressure  ratio  between 
the  compressor  inlet  and  the  turbine  outlet.  The  remaining  sensors  are  self-explanatory 
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A.  2  Hydraulic  System 


The  hydraulic  system  consists  of  two  identical  and  independent  subsystems.  Each  hydraulic  , 

t 

subsystem  consists  of  a  hydraulic  fluid  reservoir,  an  engine-driven  and  electrically-driven  pump,  and  . 

I 

an  output  line.  The  reservoir  is  instrumented  with  a  quantity  sensor.  Each  pump  has  a  pressure  i 

sensor,  as  does  the  output  line.  [ 

A. 3  Fuel  System 

The  fuel  is  stored  in  two  primary  fuel  tanks  (forward  and  aft).  Pumps  in  each  of  these  tanks 
transfer  fuel  into  left  and  right  feed  tanks,  where  boost  pumps  move  the  fuel  to  the  crossfeed  valve. 

The  crossfeed  valve  directs  the  fuel  into  the  left  and/or  right  fuel  lines,  from  which  the  cryogenic 
fuel  is  fed  to  the  engines  and  the  thermal  protection  system.  Each  fuel  line  has  a  fuel  dump  valve. 

Each  of  the  four  fuel  tanks  has  a  fuel  quantity  sensor,  and  the  fuel  lines  are  instrumented  with  fuel 
flow  sensors. 

A. J  Flight  Control  System 

The  flight  control  system  consists  of  four  primary  control  surfaces;  right  and  left  elevons. 
body  flap,  and  rudder.  Each  control  surface  is  driven  by  two  control  surface  actuators,  and  is 
instrumented  by  a  position  sensor. 

.4.5  Thermal  Protection  System 

The  thermal  protection  system  works  by  circulating  cryogenic  fuel  through  the  hot  structures 
of  the  aircraft.  These  hot  structures  include  the  leading  edges  of  the  nosecap,  wings,  and  vertical 
tail,  and  the  inlet,  nozzle,  and  internal  structure  of  the  engines.  Each  of  the  hot  structures  has  an 
associated  temperature  sensor.  The  cryogenic  fuel  is  forced  through  the  thermal  protection  system 
by  six  pumps,  each  of  which  has  a  pressure  sensor 
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Appendix  B.  Listing  of  the  NASP  System  Status  Monitor  Knowledge  Base 


(MissionA  mission  (parts  (Takeoff 

Climb 


Cruise 
Descent 
Landing ) ) 

( f unct iona 1 ly-dependent-on  (Takeoff 

Climb 
Cruise 
Descent 
Landing ) ) ) 


(Takeoff  flight-phase 


(part-of  (MissionA)) 

(parts  (Takeoff-Plane 
Total-Thrust 
Weight 
Drag 

Attitude 

Lift 

Ai r speedA 
Alt itudeA 
Cl imb-RateA ) ) 

(associated-sensors  (AirspeedA 
Al t itudeA 
Climb-RateA ) ) 

(functional-dependents  (MissionA 

Climb 
Cruise 
Descent 
Landing  )  ) 

( f unct lonal ly-dependent-on  (Takeoff-Plane 

Total-Thrust 

Weight 

Drag 

Attitude 
Lift  )  )  ) 


(Climb  flight-phase  (part-of  (MissionA)) 

(parts  (Climb-Plane 
Total-Thrust 
Weight 
Drag 

Attitude 

Lift 

MachA 

Alt itudeA 

Cl imb-RateA ) ) 

(associated-sensors  (MachA 

Alt itudeA 
Cl imb-RateA  > ) 

(functional-dependents  (MissionA 

Cruise 
Descent 
Landing l ■ 

( functional ly-dependent-on  (Takeoff 

Climb-Plane 
Tot  a  1 -Thrust 
Weight 
Drag 

Attitude 
Lift  M  ) 

(Cruise  flight-phase  (part-of  (MissionA) ) 

(parts  (Cruise-Plane 
Total-Thrust 
Weight 
Drag 

Attitude 
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Lift 

MachA 

AltitudeA) ) 

( associated-sensor s  (MachA 

Al  titudeA) ) 
(functional-dependants  (MissionA 

Descent 
Landing ) ) 

( f unct ional ly-dependent-on  (Takeoff 

Cl  imb 

Cruise-Plane 

Total-Thrust 

Weight 

Drag 

Attitude 
Lift )  ) ) 

(Descent  flight-phase  (part-of  (MissionAM 
(parts  (Descent-Plane 
Weight 
Drag 

At  t i t ude 
Lift 
MachA 
Alt itudeA 
Sink-Rat «A ) ) 

( associated-sensors  (MachA 

Alt itudeA 
Sink-RateA) ) 
(functional-dependents  (MissionA 

Landing ) ) 

( funct lona 1 ly-dependent-on  (Takeoff 

Climb 

Cruise 

Descent-Plane 

Weight 

Drag 

Attitude 
Lift  )  )  > 

(Landing  flight-phase  (part-of  (MissionAM 
(parts  (Landing-Plane 
Total-Thrust 
Weight 
Drag 

Attitude 

Lift 

Ai rspeedA 
Al t itudeA 
Sink-RateA ) ) 

(associated-sensors  (AirspeedA 
Alt itudeA 
Sink-RateA ) ) 

(functional-dependents  (MissionA) ) 

( funct ional ly-dependent-on  (Takeoff 

Climb 

Cruise 

Descent 

Landing-Plane 

Weight 

Drag 

Attitude 
Lif t  )  )  ) 


(Total-Thrust  flight-parameter  (part-of  (Takeoff 

Climb 
Cruise 
Landing ) ) 

(parts  (ThrustA 

ThrustB ) ) 

(associated-sensors  (ThrustA 

ThrustB ) ) 


( f unct ional-dependents  (Takeoff 

Climb 
Cruise 
Landing ) ) 

( f unct ional ly-dependent-on  ( Propulsion  /5ystemA 

AirspeedA 

MachA 

AltitudaA) ) 

(causas  (((increase  ThrustA) ( increase  Total-Thrust)) 
((decrease  ThrustA) ( decrease  Total-Thrust)) 
((increase  ThrustB )( increase  Total-Thrust)) 
((decrease  ThrustB )( decrease  Total-Thrust))))) 


(Weight  flight-parameter  (part-of  (Takeoff 

Climb 


Cruise 
Descent 
Landing ) ) 

(associated-sensors  (Total-Fuel-Quantity) ) 
(functional-dependents  (Takeoff 

Climb 
Cruise 
Descent 
Landing ) ) 

( functions  1 ly-dependent-on  ( Fwd-Tank-Quant i ty 

Aft -Tank-Quantity 
Feed-TankA-Quant i ty 
Feed-TankB-Quanti ty ) ) 

(causes  (((decrease  Total-ruel-Quantity )( decrease  Weight))))) 


(Drag  flight-parameter  (part-of  (Takeoff 

Climb 


Cruise 
Descent 
Landing ) ) 

(functional-dependents  (Takeoff 

Climb 
Cruise 
Descent 
Landing ) > 

( funct ionally-dependent-on  (Lift 

Ai rspeedA 

MachA 

Attitude 

Lef t-Ele von- Posit  ion 
Right-Elevon-Position 
Body-Flap-Posi t ion 
Rudder-Position) ) 

(causes  (((decrease  Weight )( decrease  Drag)) 

((increase  Lef t-Elevon-Position )( increase  Drag)) 
((decrease  Lef t-Elevon-Pos it ion )( decrease  Drag)) 
((increase  Right-Elevon-Position )( increase  Drag)) 
((decrease  Right-Elevon-Posit ion )( decrease  Drag)) 
((increase  Body-Flap-Position )( increase  Drag}} 
((decrease  Body-Flap-Posit ion )( decrease  Drag)) 
((increase  Rudder-Posi ti on )( increase  Drag)) 
((decrease  Rudder-Posit  ion )( decrease  Drag))))) 


(Attitude  flight-parameter  (part-of  (Takeoff 

Climb 


Cruise 
Descent 
Landing ) ) 

(parts  (PitchA 
RollA 
YawA) ) 

(associated-sensors  (PitchA 
RollA 
YawA) ) 

(functional-dependents  (Takeoff 

Cl  imb 

Cruise 

Descent 


Landing 
Drag 
Lift)  ) 

( f unctional ly- dependent -on  ( Lef t-Elevon-Posi t ion 

Right-El  evon-F'..*'  it  ion 
Body-F lap-Posit ion 
Ruddar-Posi t ion ) ) ) 


(Lift  flight-parameter  (part-of  (Takeoff 

Climb 


Cruise 
Descant 
Landing ) ) 

(functional-dependants  (Takeoff 

Climb 
Cruise 
Descent 
Landing 
Drag )  ) 

( functionally-dependent-on  (Weight 

At  t i tuda 
Ai rspeedA 
MachA 

Lef t-Elevon-Posit ion 
Right-Elavon-Posi t ion 
Body-Flap-Position) ) ) 


(AirspeedA  ai rcraf t-sansor  (part-of  (Takeoff 

Landing ) ) 


(associated-component  (Takaoff 

Landing ) ) 

(association-type  ((Takaoff  parameter) 

(Landing  parameter))) 

( functional-dependants  (Total-Thrust 

Drag 
Lift)  ) 

(causes  (((increase  Total-Thrust )( increase  AirspeedA)) 
((decrease  Total-Thrust )( decrease  AirspeedA)) 
((increase  Drag )< decrease  AirspeedA)) 
((decrease  Dr ag )( increase  AirspeedA)) 
((increase  Pi tchA )( decrease  AirspeedA)) 
((decrease  Pi tchA ) ( inc rease  AirspeedA)) 
((increase  AltitudeA) ( decrease  AirspeedA)) 
((decrease  AI t i tudeA )( increase  AirspeedA))))) 

(AltitudeA  aircraft-sensor  (part-of  (Takeoff 

Climb 
Cruise 
Descent 
Landing ) ) 

( associated-component  (Takeoff 
Climb 
Cruise 
Descent 
Landing ) ) 

(association-type  ((Takeoff  parameter) 

(Climb  parameter) 

(Cruise  parameter) 

(Descent  parameter) 

(Landing  parameter))) 

( funct iona 1 -dependents  (Total-Thrust) ) 

(causes  (((increase  AirspeedA) ( increase  AltitudeA)) 
((decrease  Ai rspeedA )( decrease  Altitude)) 
((increase  MachA )( inc rease  AltitudeA)) 
((decrease  MachA )( decrease  Altitude)) 
((increase  Pi tchA )( increase  AltitudeA)) 
((decrease  Pi tchA )( dec rease  Altitude))))) 

(Climb-RateA  aircraft-sensor  (part-of  (Takeoff 

Climb) ) 

(associated-component  (Takeoff 
Climb) ) 

(association-type  ((Takeoff  parameter) 
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(Climb  parameter))) 

Icausts  (((incraasa  AirspeedA) ( incraasa  Climb-RataA) ) 

( (daccaasa  Ai rspaadA) ( dacraase  Climb-RataA)) 
((incraasa  MachA) ( incraasa  Climb-RataA)) 
((dacraasa  MachA)  (  dacraase  ClimL--RateA)  ) 
((incraasa  PitchA) ( incraasa  Climb-RataA)) 
((dacraasa  PitchA )( dacraase  Climb-RataA)) 
((dacraasa  Weight )( incraasa  Climb-RataA))))) 

(MachA  ai rcraf t-sansor  (part-of  (Climb 

Cruise 
Descent )  ) 

(associated-component  (Climb 
Cruise 
Descant ) ) 

(association-type  ((Climb  parameter) 

(Cruise  parameter) 

(Descent  parameter))) 

( functional-dependents  (Total-Thrust 

Drag 
Lift) ) 

(causes  (((increase  Total-Thrust )( increase  MachA)) 

((decrease  Total-Thrust )( decrease  MachA)) 

((decrease  Drag )( increase  MachA)) 

((increase  Drag )( decrease  MachA)) 

((decrease  PitchA) ( increase  MachA)) 

((increase  PitchA) (decrease  MachA)) 

((decrease  AI t itudeA )( increase  MachA)) 

((increase  AltitudeA) ( decrease  MachA))))) 

(Sink-RateA  aircraft-sensor  (part-of  (Descent 

Landing )  ) 

(associated-component  (Descent 

Landing ) ) 

(association-type  ((Descent  parameter) 

(Landing  parameter))) 

(causes  (((increase  AirspeedA) ( increase  Sink-RateA)) 
((decrease  Ai rspeedA) ( decrease  Sink-RateA)) 
((increase  MachA) ( increase  Sink-RateA)) 
((decrease  MachA) (decrease  Sink-RateA)) 
((decrease  PitchA) ( increase  Sink-RateA)) 
((increase  Pi tchA )( decrease  Sink-RateA)) 
((decrease  Weight )( decrease  Sink-RateA))))) 

(PitchA  aircraft-sensor  (part-of  (Attitude)) 

(associated-component  (Attitude) ) 

(association-type  ((Attitude  parameter))) 

(causes  (((increase  Body-Flap-Posit  ion )( increase  PitchA) I 
((decrease  Body-Fl ap-Position )( decrease  PitchA)) 
((increase  Fuel-Imbalance )( increase  PitchA)) 
((decrease  Fuel-Imbalance )< decrease  PitchA))))) 

(RollA  aircraft-sensor  (part-of  (Attitude)) 

( associated-component  (Attitude) ) 

(association-type  ((Attitude  parameter))) 

(causes  (((decrease  Lef t-Elevon-Posit ion )( increase  RollA)) 
((increase  Left-Elevon-Position ) (decrease  RollA)) 
((increase  Right-Elevon-Pos i t ion )( increase  RollA)) 
((decrease  Righ t-El evon-Posi t ion ) ( dec rease  RollA))))) 

(YawA  aircraft-sensor  (part-of  (Attitude)) 

( associated-component  (Attitude) ) 

(association-type  ((Attitude  parameter))) 

(causes  (((increase  Rudder-Position )( increase  YawA)) 

((decrease  Rudder-Position ) (decrease  YawA) ) ) I ) 

(Takeoff-Plane  plane  (part-of  (Takeoff!) 

(parts  ( Propulsion-SystemA 
Hydraulic-SystemA 
Fuel-SystemA 
Flight-Control-SysA ) ) 

( functional-dependents  (Takeoff  I  ) 

( functions  1 ly-dependent-on  (Propulsion-SystemA 
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Hydraul ic-Sys temA 
Fuel-SystemA 
Flight-Control-SysA) ) ) 

( Cl imb-Plane  plana  (part-of  (Climb)) 

(parts  (Propulsion-SystemA 
Hydraul ic-Sy s tamA 
Fuel-SystemA 
Flight-Cont rol-Sys A 
Thermal-Protection-SysA ) ) 

( f unct ional-dapandants  (Climb)) 

( f unct ional ly-dependent-on  ( Propulsion-SystemA 

Hydraul ic-SystemA 
Fual-SystemA 
Flight-Cont rol-SysA 
Thermal-Protection-SysA ) ) ) 

(Cruise-Plane  plana  (part-of  (Cruise)) 

(parts  (Propulsion-SystemA 
Hydraul ic-Sys tamA 
Fuel-Sys  tamA 
Flight-Cont  rol-Sys A 
Thermal-Protection-SysA) ) 

( f unctiona 1-dependant s  (Cruise)) 

( f unct ional ly-dapandant-on  ( Propulsion-SystemA 

Hydraul ic-Sys tamA 
Fuel-SystemA 
Flight-Cont rol-Sys A 
Tharmal-Protaction-SysA ) ) ) 

(Descant-Plane  plane  (part-of  (Descent)) 

(parts  (Propulsion-SystemA 
Hydraul ic-Sys tamA 
Fuel-SystemA 
Flight-Cont  rol-Sys A 
Tharmal-Protaction-SysA) ) 

( f unct ional-depandant s  ( Descant ) ) 

( funct ionally-dependent-on  ( Propulsion-SystemA 

Hydraul ic-Sys tamA 
Fuel-SystemA 
Flight-Cont  rol-Sys A 
The rma 1-Protect ion-SysA ) ) ) 

(Landing-Plane  plane  (part-of  (Landing)) 

(parts  (Propulsion-SystemA 
Hydraul ic-Sys tamA 
Fuel-SystemA 
Flight-Cont rol-SysA ) ) 

( f unct iona 1 -dependent s  (Landing ) ) 

( funct ional ly-dependent -on  ( Propulsion-SystemA 

Hyde aul ic-Sys tamA 
Fuel-SystemA 
Flight-Control-SysA) ) ) 


(Propulsion-SystemA  aircraft-system  (part-of  (Takeoff-Plane 

Climb-Plane 
Cruise-Plane 
Descent-Plane 
Landing-Plane ) ) 

(parts  (EngineA 

EngineB ) ) 

( functional-dependents  (Takeoff-Plane 

Climb-Plane 
Cruise-Plane 
Descent-Plane 
Landing-Plane 
Total-Thrust ) ) 

( functionally- dependent-on  (EngineA 

EngineB ) ) > 

(EngineA  engine  (part-of  (Propulsion-SystemA)) 


yjJSX’Mf.’JTSWW'jrjrjvjr.^ 


(parts  (InlatA 


K 


CompressorA 

GaarboxA 

Elect ric-GeneratorA 

Gas-GeneratorA 

TurbineA 

Fuel -In jectorA 

Combusto  rA 

NozzleA 


* 

L 
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N1A 
Epr  A 
Egt  A 

VoltageA 
ThrustA 
VibrationA) ) 

< associatad-sansors  (VibrationA 
ThrustA) ) 

{ f unct lonal -dependents  ( Propul  5 ion-SystemA 

ThrustA 
VibrationA) ) 

( functional ly-dependent-on  ( InlatA 

CompressorA 

GaarboxA 

Gas -Gene ratorA 

TurbineA 

Fuel-In jacto  rA 

CombustorA 

Nozz laA) ) ) 


(InlatA  engine-component  (part-of  (EngineA)) 

(associated-sensors  ( Engine-Ini et-Tamp ) ) 
(functional-dependents  (EngineA 

CompressorA) ) ) 


(CompressorA  engine-component  (part-of  (EngineA)) 

(associated-sensors  (N1A 

Epr A ) ) 

( Cunctional-dependents  (EngineA 

N1A 
Epr  A 

CombustorA) ) 

(physical-dependents  ( NlA 

GaarboxA ) ) 

( f unctionally-dependent-on  (GaarboxA) ) ) 


(GaarboxA  engine-component 


(part-of  (EngineA)) 

(functional-dependents  (EngineA 

CompressorA 

Elect  r ic-Generat or A 

Engine-Hyd-PumpAl ) ) 

(  f unct ional ly-dependent-on  (TurbineA) )  ) 


( Elect r ic-Generator A  engine-component  (part-of  (EngineA)) 

( associated-senso rs  (VoltageA)) 

( functional-dependents  ( Elect r ic-Hyd-PumpA2 

Fwd- Elec-Cool ing-Pump 
Left-Elec-Cooling-Pump) ) 
( f unctionally-dependent-on  (GaarboxA) ) ) 


( Gas-Generator A  engine-component  (part-of  (EngineA)) 

(functional-dependents  (EngineA 

TurbineA) ) 

( f unct iona 1 ly-dependent-on  (Fuel-LineA) ) 
'physical-dependents  (TurbineA) ) ) 

(TurbineA  engine-component  (part-of  (EngineA)) 

(associated-sensors  (EgtAl) 
(functional-dependents  (EngineA 

Eg  t  A 

GaarboxA  >  ) 

(physical-dependents  < Egt A 

Fue 1 - LineA ) ) ' 
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(  Fuel-In}ectorA  engine-component  (p«rt-of  (EngineA)) 

( f unct ional-dependents  (EngineA 

CombustorA) ) 

( function® 1 ly-dependent-on  ( Fuel-Lin«  A ) ) ) 

(CombustorA  engine-component  (part-of  (EngineA)) 

(associated-sensors  ( Epr A ) ) 
(functional-dependents  (EnginaA 

EprA) ) 

( functionally-dapandant-on  (ComprassorA 

Fuel-In jectotA ) ) ) 

(NozzleA  engine-component  (part-of  (EnginaA)) 

( funct lonal-dependent s  (EnginaA 

ThrustA) ) ) 

(NlA  engine-sensor  (part-of  (EnginaA)) 

( associated-component  ( ComprassorA) ) 

( associat ion-typa  ((ComprassorA  paramatar))) 

(causas  (((incraasa  Epr A ) ( incr aasa  NlA)) 

((dacreasa  EprA ) ( dacraasa  NlA))))) 

(EprA  angi na-sanso r  (part-of  (EnginaA)) 

( associatad-componant  (ComprassorA 
CombustorA) ) 

( associat ion-typa  ((CombustorA  output) 

(ComprassorA  input))) 

(causas  (((increase  NlA )( incraasa  EprA)) 

((decrease  NlA )( dacraasa  EprA))))) 

( EgtA  angina-sansor  (part-of  (EnginaA)) 

(associated-component  (TurbmeA)  ) 

(association-type  ( (TurbineA  output))) 

(causas  (((increase  NlA )( dacraasa  EgtA)) 

((decrease  NlA ) ( inc reas a  EgtA)) 

((increase  Fuel-FlowA ) ( inc raase  EgtA)) 
((decrease  Fuel-FlowA) < decrease  EgtA))))) 

(VoltageA  ang 1 na-sanso r  (part-of  (EnginaA)) 

(associated-component  ( Elect ric-GeneratorA) ) 
(associat ion-typa  (( Elect ric-Ganara torA  output))) 
(causas  (((increase  N1 A ) ( inc raase  VoltageA)) 

((decrease  Nl A ) ( dec raase  VoltageA))))) 


(ThrustA  angina-sanso r 


(part-of  (EnginaA)) 

(associated-component  (EnginaA 

Total-Thrust ) ) 

(association-type  ((EngineA  output) 

(Total-Thrust  parameter))) 

(causas  (((increase  EprA )( increase  ThrustA)) 
((decrease  Epr A )( decrease  ThrustA)) 
((increase  Fuel-FlowA >( increase  ThrustA)) 
((decrease  Fuel-FlowA) ( decrease  ThrustA)))) 


(VibrationA  angina-sanso r  (part-of  (EnginaA)) 

(associated-component  (EngineA)) 

(association-type  ((EngineA  parameter))) 

(causes  (((increase  NlA ) ( inc raase  VibrationA)) 

((decrease  NlA )( decrease  VibrationA))))) 


(EngineB  engine  (part-of  ( Propul s lon-SystemA ) l 
(parts  (  Inlet B 

CompressorB 
Gea  rboxB 

Elect r ic -Genera  tor B 

Gas-GeneratorB 

TurbineB 

Fuel-InjectorB 

Combus  to  r B 

Nozz leB 


Egt  B 

VoltageB 
Thrus tB 
Vibrat ionB  > ) 

( associated-sensor s  (VibrationB 
Thrust  B ) ) 

( functionally-dependent-on  ( InletB 

ComprassorB 
GaarboxB 
Gas-GeneratorB 
Tu  rbineB 
Fual-In jactorB 
CombustorB 
NozzleB ) ) 

( functions 1-dapandants  ( Propulsion-SystemA 

ThrustB 
Vibrat ionB ) ) ) 

(InlatB  engine-component  (part-of  (EnginaB)) 

( associated-sensors  ( Engine-Inlet-Temp ) ) 

( f unctional-dapandant s  (EnginaB 

ComprassorB  )  )  ) 

( Compressors  engine-component  (part-of  (EnginaB)) 

(associated-sensors  (NIB 

EprB I ) 

(functional-dependants  (EnginaB 

NIB 

EprB 

CombustorB ) ) 

(physical-dependents  (NIB 

Gea  rboxB )  ) 

( functionally-dependent-on  ( Gea rboxB ) ) ) 

(GaarboxB  engine-component  (part-of  (EnginaB)) 

(functional-dependants  (EnginaB 

ComprassorB 

Elect r ic-GeneratorB 

Engme-Hyd-PumpBl  )  ) 

(functionally-dependent-on  (TurbineB) ) ) 

( Elect ric-Genera torB  engine-component  (part-of  (EngineB)) 

(associated-sensors  (VoltageB)) 

( functional-dependents  ( Elect r ic-Hyd-PumpB2 

Right-Elec-Cooling-Pump) ) 
(functionally-dependent-on  (GaarboxB) ) ) 

( Gas-Gene rato rB  angina-component  (part-of  (EnginaB)) 

(functional-dependents  (EngineB 

TurbineB 1 ) 

(functionally-dependent-on  (Fuel-LineB) > 
(physical-dependents  (TurbineB)  )  ) 

(TurbineB  engine-component  (part-of  (EngineB)) 

(associated-sensors  (EgtBM 
(functional-dependents  (EngineB 

Egt  B 

Gea  rboxB  >  ) 

(physical-dependents  (EgtB))) 

( Fuel-In jactorB  engine-component  (part-of  (EngineB)) 

( funct i ona 1 -dependent s  (EngineB 

CombustorB ) > 

(functionally-dependent-on  (Fuel-LineB) ) ) 

(CombustorB  engine-component  (part-of  (EngineB)) 

(associated-sensors  (EprB)) 

(functional-dependents  (EngineB 

EprB ) ) 

( functiona 1 ly-dependen t -on  >  ComprassorB 

Fuel - In }ec t o  rB  )  >  > 

(NozzlaB  engine-component  (part-of  (EngineB)) 


( f unct iona 1-dependents  (EngineB 

Thrust B ) ) ) 

(NIB  engint-sensor  (part-of  (EngineB)) 

(associated-component  ( Compressor B ) ) 

(association-type  ( ( Compre s so r B  parameter ))) 

(causes  (((increase  EprB)  (  increase  NlBM 

((decrease  Epr  B  )  (  dec  tease  NlBM))) 

(EprB  engine-sensor  (part-of  (EngineB)) 

( associated-component  ( Compressors 
Combus to rB )  ) 

( as socia t ion-type  ((CombustorB  output) 

(Compressors  input))) 

(causes  (((increase  N1 B ) ( inc tease  EprB)) 

((decrease  N1 B ) ( dec rease  EprB))))) 

(EgtB  engine-sensor  (part-of  (EngineB)) 

(associated-component  (TurbineB) ) 

(association-type  ((TurbineB  output))) 

(causes  (((increase  Nl B )( dec rease  EgtB)) 

((decrease  NIB )( increase  EgtB)) 

((increase  Fuel-FlowB )( increase  EgtB)) 
((decrease  Fuel-FlowB )( decrease  EgtB))))) 

(VoltageB  engine-sensor  (part-of  (EngineB)) 

(associated-component  ( Elect ric-G#n#ratorB ) ) 

( associ a t ion-type  ( f El ect ric-Genera t orB  output))) 
(causes  ((increase  Nl B ) ( increas *  VoltageB)) 

((decrease  Nl B )( deer  ease  VoltageB)))) 

(ThrustB  engine-sensor  (part-of  (EngineB)) 

(associated-component  (EngineB 

Total-Thrust ) ) 

(association-type  ((EngineB  output) 

(Total-Thrust ) ) ) 

(causes  (((increase  EprB )( increase  ThrustB)) 
((decrease  EprB )( decrease  ThrustB)) 
((increase  Fu* l-F lowB ) ( inc rea se  ThrustB)) 
((decrease  Fuel-FlowB )( decrease  ThrustB))))) 

(VibrationB  engine-sensor  (part-of  (EngineB)) 

(associated-component  (EngineB)) 

(association-type  ((EngineB  parameter))) 

(causes  (((increase  Nl B )( inc rease  VibrationB)) 

((decrease  NIB )( decrease  VibrationB))))) 


{  Hydr aul ic-Sys temA  aircraft-system  (part-of  ( Ta keof f -Pi ane 

Climb-Plane 
Cruise-Plane 
Descent-P 1 ane 
Landing-Plane) ) 

(parts  ( Hydraulic-SubsystemA 

Hydraul ic-Subsys temB ) ) 

( functional-dependents  ( Takeof f -PI ane 

Cl imb-Plane 
Cruise-Plane 
Descent -Plane 
Landing- Plane  >  ) 

( functionally-dependent-on  (Hydraul 1 c-Subsys t  eaA 

Hydr au 1 i c-Subsys temB ' ) 

(  Hydraul ic-Subsys temA  hydraul ic-subsys tem  (part-of  ( Hydraul ic-Sys temA ? ) 

(parts  ( Hydr aul lc-LineA 

Hyd-SubsysA-Pressure 
Eng i ne -Hy d- Pump A1 
E  1  ec t  r i c-Hy d-PumpA2 
Hydraul ic -Resevoi r A 
Hyd-PumpAl -Pressure 
Hyd-PumpA2 -Pressure 


Hyd-Quant ityA) ) 

( functions  1 -dependents  ( Hydraul ic-Sys t amA ) ) 

( f unctionally-dependent-on  ( Hydraul ic-Lin«A ) ) ) 

(  Hydraul lc-lineA  hydraulic-line  (part-of  ( Hydraul ic-Subsys temA ) ) 

(associated-sensors  ( Hyd-SubsysA-Pressure )  > 

( functional-dependants  ( Hydraulic-SubsystemA 

Hyd-SubsysA-Pressure 
Lef t-Elevon-Actuato  r-1 
Right-Elevon-Actua tor-1 
Body-Flap-Actua tor-1 
Ruddar-Actuator-1 
Right-Hyd-Cooling-Pump ) ) 

( f unct ional ly-dependent-on  ( Engine-Hyd-PumpAl 

Elect r ic-Hyd-PumpA2 ) ) 

(physical-dependants  ( Hyd-SubsysA-Pressure ) ) ) 

( Hyd-SubsysA-Prassure  hyd-pressure  (part-of  < Hydraul ic-SubsystemA ) ) 

( associated-component  ( Hydraul ic-LineA ) ) 
(association-type  (( Hydraul ic-LineA  parameter)))) 

( Engine-Hyd-PumpAl  hydraulic-pump  (part-of  (Hydraulic-SubsystemA)) 

( associa ted-senso rs  < Hyd-PumpAl-Pressure ) ) 

( functional ly-dependent-on  ( Gaa rboxA 

Hydraul ic-Rasevoi rA ) ) 

(functional-dependents  ( Hydraul ic-LineA ) ) ) 

( Elect ric-Hyd-PumpA2  hydraulic-pump  (part-of  (Hydraulic-SubsystemA)) 

(associated-sensors  ( Hyd-PumpA2-Pressure ) ) 

( f unctionally-dependent-on  ( Electric-GeneratorA 

Hydraulic-Resevoi rA ) ) 

( functional-depandents  ( Hydraul ic-LineA ) ) ) 

( Hydraul ic-Resevoi rA  hydraul ic-resevoi r  (part-of  (Hydraulic-SubsystemA)) 

(associated-sensors  ( Hyd-Quant ityA ) ) 

( functional-dependents  ( Engine-Hyd-PumpAl 

Elect ric-Hyd-PumpA2 ) ) ) 

( Hyd-PumpAl-Pressure  hyd-pressure  (part-of  (Hydraulic-SubsystemA)) 

( associated-component  ( Engine-Hyd-PumpAl ) ) 
(association-type  ( ( Engine-Hyd-PumpAl  parameter) 

)  )  ) 

;  Hyd-PumpA2-Pressure  hyd-pressure  (part-of  (Hydraulic-SubsystemA)) 

(associated-component  ( Elect ric-Hyd-PumpA2 ) ) 

( associat ion-type  (( Elect ric-Hyd-PumpA2  parameter)))) 

( Hyd-Quant ityA  hyd-quantity  (part-of  (Hydraulic-SubsystemA) ) 

( associa t ed-componen t  ( Hydraul ic-Resevoi rA ) ) 
(association-type  (( Hydraul ic-Resevo i rA  parameter)))) 


( Hydraul ic-Subsys temB  hydraul ic-subsys t em  (part-of  ( Hydraul i c-SystemA ) ) 

(parts  (Hydraulic-LineB 

Hyd-SubsysB-Pressure 
Engine-Hyd-PumpBl 
Elect  r ic-Hyd-PumpB2 
Hydraulic-Resevoi r B 
Hyd-PumpBl -Pres  sure 
Hyd-PumpB2 -Pres sure 
Hyd-Quant i tyB ) ) 

(functional-dependents  ( Hydraulic-SystemA ) ) 

( functions  1 ly-dependent-on  ( Hydraulic-LineB )  ) ) 

(Hydraulic-LineB  hydraul ic- 1 ine  'part-of  ( Hydraul lc-SubsystemB ) > 

(associated-sensors  (Hyd-SubsysB-Pressure)  ) 

( f unct iona 1 -da pendent  s  (Hydraul ic-Subsys  temB 

Hyd-SubsysB-Pressure 
Lef t-Elevon-Ac tua t o  r -2 
Right-Ele'  :>n-Actuator-2 
Body-F lap- Ac tua  t o  r- 2 
Rudde  r-Actua t o  r-2 
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Fwd-Hyd-Cool ing-Pump 
Left-Hyd-Cool ing-Pump ) ) 
(physical-dependents  ( Hyd-SubsysB-Pres su r a ) ) ) 

( Hyd-SubsysB-Pressure  hyd-j.  r essur#  (part-of  ( Hydr aul ic-SubsystemB ) ) 

( associated-component  ( Hydraul ic-Lx neB ) ) 
(association-type  (( Hydraul ic-LineB  parameter)))) 

( Engina-Hyd-PumpBl  hydraulic-pump  (part-of  ( Hydraul ic-Subsys tamB ) ) 

( associated-sensors  I Hyd-PumpBl-Pressure ) > 

( f unctional ly-dependent-on  (GearboxB 

Hydraul ic-R«s«vox rB ) ) 

( f unct ional-dapandants  ( Hydr aul ic-LineB ) ) ) 

t Elect r ic-Hyd-PurapB2  hydraulic-pump  (part-of  ( Hydraul ic-Subsys tamB ) ) 

( associated-sensors  ( Hyd-PumpB2-Prassura ) ) 

( funct ionally-dapandant-on  ( El ac t ric-Ganar a torB 

Hydraul ic-Rasavoi rB ) ) 

( f unct ional-dapandants  ( Hydraul ic- Li naB ) ) ) 

( Hydraulic-Rasavoi rB  hydraul ic-rasavoi r  (part-of  ( Hydr aulic-Subsys tamB ) ) 

( associa tad-sansors  ( Hyd-Quant i tyB ) ) 

( functional-dependents  <  Engina-Hyd-PumpBl 

Elact r ic-Hyd-PumpB2 ) ) ) 

( Hyd-PumpBl-Prassura  hyd-prassura  (part-of  ( Hydr aul ic-SubsystamB I ) 

( associatad-componant  ( Engina-Hyd-PumpBl ) ) 

( associat ion-typa  ((Engina-Hyd-PumpBl  paramatar ) ) ) > 

( Hyd-PumpB2-Prassura  hyd-prassura  (part-of  ( Hydraul ic-Subsys tamB ) ) 

( associa tad-componant  ( Elact ric-Hyd-PumpB2 ) l 
( associat ion-typa  (( Elact ric-Hyd-PumpB2  paramatar)))) 

( Hyd-Quant ityB  hyd-quantity  (part-of  ( Hydraul ic-Subsys tamB ) ) 

( associatad-componant  ( Hydraul ic-Rasavoi rB ) ) 

( associat ion-typa  (( Hydraul ic-Rasavoi rB  paramatar)))) 


( Fual-SystamA  a i r c r a f t-sy s tarn  (part-of  ( Takaof f-Plana 

Climb-Plane 
Cruisa-Plana 
Dascant-Plana 
Landing-Plane ) ) 

(parts  I Fwd-Fuel-Tank 
Aft -Fuel -Tank 
EngineA-Feed-Tank 
Eng ineB- Feed-Tank 
Fwd-Tank-Trans  f a r -Pump 
Af t -Tank -Trans  fa  r- Pump 
Eng ineA-Tank- Boos t -Pump 
Eng ineB-Tank -Boost -Pump 
Fuel-LineA 
Fuel-LineB 
Cross f a ad- Valve 
Fuel-Dump-Va 1 vaA 
Fuel -Dump- Va 1 veB 
Fual-FlowA 
Fual-FlowB 
Fwd-Tank-Quanti ty 
Af  t-Tank -Quant ity 
Feed-TankA-Quant i ty 
Feed-TankB-Quant i ty 
Tot  a  1 -Fuel -Quant i ty 
Boo st-PumpA- Pres  sure 
Boos t-PumpB- Pres sura 
Fuel-Imbalance ) ) 

( associate d-sensors  ( Tot al-Fuel-Quant i ty 
Fuel-Imbalance ) ) 

! functional-dependents  ( Takaof f-Plane 

Climb-Plane 
C  rui sa-Pl ane 
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Descent-Plane 
Landing-Plan# ) ) 

( functionally-dependent-on  ( Fwd- Fuel -Tank 

Af t-Fu#l-Tank 
EngineA-Fee*l-Tank 
Engin#B-F##d-Tank 
Fu#l-Lin#A 
Fu#l-Lin#B 
Cross f ##d-Valv# 
Fuel-Dump-Val veA 
Fuel-Dump-Val veB ) ) ) 

( Fwd-Fuel-Tank  fu#l-tank  (part-of  ( Fu# 1-Sys t#mA ) ) 

(associated-sensors  < Fwd-Tank-Quant i ty ) ) 

(  f unctional-d#p#nd#nts  ( Fu# 1-Sys t#mA 

Fwd-Tank-Transf #r-Pump ) ) ) 

( Af t-Fu#l-Tank  fu#l-tank  (part-of  (Fuel-SystemA)) 

(associated-sensors  (Aft-Tank-Quantity) ) 

( f unct iona 1 -dependents  ( Fuel-SystemA 

Aft-Tank-Transfer-Pump) ) ) 

( EngineA-Feed-Tank  fuel-tank  (part-of  (Fuel-SystemA)) 

( associated-sensors  < Feed-TankA-Quant i ty ) ) 

( functional -depen dents  (Fuel-SystemA 

EngineA-Tank-Boos t-Pump ) ) ) 

( EngineB-Feed-Tank  fuel-tank  (part-of  (Fuel-SystemA)) 

(associated-sensors  ( F##d-TankB-Quant i ty ) ) 

( f unct iona 1 -dependent s  ( Fu#l-SystemA 

Engin#B-Tank-Boost-Pump ) ) ) 

( Fwd-Tank-Transf er-Pump  fuel-pump  (part-of  f Fuel-Sys temA ) ) 

( functional-dependents  ( EngineA-Feed-Tank 

EngineB-Feed-Tank ) ) 

( funct ionally-dependent-on  ( Fwd-Fuel-Tank ) ) ) 

(Aft-Tank-Transfer-Pump  fuel-pump  (part-of  (Fuel-SystemA)) 

( functional-dependents  ( EngineA-Feed-Tank 

EngineB-Feed-Tank ) ) 

( functionally-dependent-on  (Aft-Fuel-Tank ) ) ) 

( EngxneA-Tank-Boost-Pump  fuel-pump  (part-of  (Fuel-SystemA)) 

(functional-dependents  ( Cross feed-Va 1 ve } ) 

( functionally-dependent-on  ( EngineA-Feed-Tank ) ) ) 

( EngineB-Tank-Boost-Pump  fuel-pump  (part-of  (Fuel-SystemA)) 

(functional-dependents  (Crossfeed-Valve) ) 
(functionally-dependent-on  (EngineB-Feed-Tank) )  ) 

( Cross feed-Va 1 v#  fuel-valve  (part-of  (Fuel-SystemA)) 

(funct iona 1 -dependent s  (Fuel-SystemA 

Fuel- Dump- Va 1 veA 
Fuel-Dump-Va 1 veB 
Fuel-LineA 
Fuel-LineB ) ) 

( functionally-dependent-on  ( EngineA-Tank-Boos t -Pump 

EngineB-Tank-Boost-Pump) ) ) 

( Fuel-Dump-Val veA  fuel-valve  (part-of  (Fuel-SystemA)) 

(functional-dependents  (Fuel-SystemA) ) 

( funct iona 1 iy-dependent-on  ( Cross feed-Va 1 ve )  )  t 

( Fue 1 -Dump-Va 1 v#B  fuel-valve  (part-of  (Fuel-SystemA)) 

(functional-dependents  (Fuel-SystemA) ) 
(functionally-dependent-on  (Crossfeed-Valve) ) ) 

(Fuel-LineA  fuel-line  (part-of  (Fuel-SystemA)) 

(associated-sensors  (Fuel-FlowA) ) 

(functional-de pendents  <  Fuel-SystemA 

Gas-Genera torA 
Fuel- In  ject orA 
Fwd-Hyd-Coo 1 ing-Pump 


I 


>,*  V 


Right-Hyd-Cool ing-Pump 
Left-Elec-Cooling-Pump) ) ) 


(Fuel-LineB  fuel-line  (part-of  (Fuel-SystemA)) 

(associated-sensors  (Fuel-rlowB) ) 

( funct ional-dependent s  ( Fuel-SystemA 

Gas-GeneratorB 
Fuel-In jectorB 
Fwd-Elec-Coo ling- Pump 
Right -Elec-Cool ing-Pump 
Laf t-Hyd-Cool ing-Pump ) ) ) 


(Fual-FlowA  fuel-flow  (part-of  (Fuel-SystemA)) 

{ associa tad-componant  (Fual-LinaA) ) 

(association-type  ((Fual-LinaA  parameter))) 

(causes  (((increase  Boos t-PumpA-Pressure )( increase  Fuel-FlowAM 

((decrease  Boos  t-PumpA-Pressure  M  decrease  Fuel-PlowA  )))>  ) 

(Fual-FlowB  fual-flow  (part-of  ( Fuel-SystemA ) ) 

(associated-component  (Fuel-LineB) ) 

(association-type  ((Fuel-LineB  parameter))) 

(causes  (((increase  Boos t-PumpB-Pressure )( increase  Fuel-FlowBM 

((decrease  Boos t-PumpB-Prassura )( decrease  Fuel-FlowB ) ) ) ) > 

< Fwd-Tank-Quant i ty  f uel-qty-sensor  (part-of  ( Fual-Sys tamA ) ) 

(associated-component  ( Fwd-Fuel-Tank ) ) 
(association-type  ( ( Fwd-Fuel-Tank  parameter))) 

( functional-dependants  (Weight ) ) ) 

(Aft-Tank-Quantity  f uel-qty-sensor  (part-of  ( Fuel-SystemA ) ) 

( associated-component  (Aft-Fuel-Tank) ) 
(association-type  ((Aft-Fuel-Tank  parameter))) 

( functional-dependents  (Weight ) ) ) 

( Feed-TankA-Quantity  f uel-qty-senso r  (part-of  (Fuel-SystemA)) 

(associated-component  ( EngineA-Feed-Tank ) > 
(association-type  ((EngineA-Feed-Tank  parameter))) 

( functional-dependents  (Weight ) ) ) 

( Feed-TankB-Quant lty  f uel-qty-senso r  (part-of  (Fuel-SystemA)) 

(associated-component  ( EngineB-Feed-Tank ) ) 
(association-type  ((EngineB-Feed-Tank  parameter))) 
(functional-dependents  (Weight ) ) ) 

{ Boos t-PumpA-Pressure  sensor  (part-of  (Fuel-SystemA))) 

( Boos t-PumpB-Pressure  sensor  (part-of  (Fuel-SystemA))) 

(Total-Fuel-Quantity  fuel-qty-sensor  (part-of  (Fuel-SystemA)) 

( associated-component  (Fuel-SystemA 
Weight )  ) 

( assocat ion-type  ((Fuel-SystemA  parameter* 

(Weight  parameter ) ) ) ) 

(Fuel-Imbalance  fuel-qty-sensor  (part-of  (Fuel-SystemA)) 

(associated-component  (Fuel-SystemA) ) 

(association-type  ( ( ^uel-Sys temA  parameter)))* 


( FI lght-Cont rol-SysA  aircraft-system  (part-of  (Takeoff-Plane 

Cl i mb-P 1 ane 
Cruise-Plane 
Descent-Plane 
Landing-Plane ) » 
(parts  (Left-Elevon 
Pight-Elevon 
Body-Flap 
Rudde  r 

Con t  ro 1 -St lck 
Le  f  t -Rudde  r- Pe da  1 
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Right-Rudder-Pedal 
Lef t-E la von- Actuator- 1 
Lef t-E levon-Actua tor-2 
Lef t-Elevon-Posi t ion 
Right-Elevon-Actuator-1 
Right-E levon-Actua tor- 2 
Right-Elevon-Posi t ion 
Body-Flap-Actuator-L 
Body-Flap-Actuator- 2 
Body-Flap-Position 
Rudde  r-Actua to  r-1 
Rudda  r -Actuator- 2 
Rudder-Position) ) 

( functional-dependents  (Takeoff-Plane 

Cl imb-Plane 
Cruise-Plane 
Descent-Plane 
Landing-Plane ) ) 

( functionally-dependent-on  ( Left-Elevon 

Right-Elevon 
Body-Flap 
Rudder ) ) ) 

(Left-Elevon  control-surface  (part-of  ( Flight-Control-SysA) ) 

(associated-sensors  ( Lef t-Elevon-Posi t ion ) ) 

( f unction a  1 -dependents  ( FI ight-Cont rol-SysA 

Lef t-Elevon-Posit ion ) ) 

( functionally-dependent-on  ( Lef t-Elevon-Actuator-1 

Lef t-Elevon-Actuator-2 ) > ) 

(Right-Elevon  control-surface  (part-of  ( Flight-Cont rol-SysA) ) 

(associated-sensors  ( Right-Elevon-Posi t ion )  ) 

{ functional -dependents  ( FI ight-Cont rol-Sy s A 

Right-Elevon-Posit ion )  ) 

( functionally-dependent-on  ( Right-Elevon-Actuato r-1 

Right-Elevon-Actuator-2 ) )  ) 

(Body-Flap  control-surface  (part-of  ( Fl ight-Cont rol-SysA ) ) 

(associated-sensors  (Body-Flap-Position) ) 

( functional -dependents  ( Fl ight-Cont rol-SysA 

Body-Flap-Position) ) 

( functionally-dependent-on  ( Body-Flap-Actuator-1 

Body-Flap-Actuator-2 ) ) ) 

(Rudder  control-surface  (part-of  ( F 1 l ght-Cont r o 1-Sy sA ) ) 

(associated-sensors  (Rudder-Position) ) 

( functional -dependents  ( Fl ight-Cont i ol-Sys A 

Rudder-Position) ) 

( functional ly-dependent-on  ( Rudde r-Actua to r-1 

Rudder-Actuator-2) ) ) 

(Control-Stick  component  (part-of  ( Fl ight-Cont rol-SysA) ) ) 

(Left-Rudder-Pedal  component  (part-of  ( Fl ight-Cont rol-SysA ) ) ) 

(Right-Rudder-Pedal  component  (part-of  ( F 1 ight -Cont ro 1 -SysA  )  ) ) 

( Lef t-Elevon-Actuator-1  cont ro 1 -sue f ace-actua t o r  (part-of  ( Fl ight-Cont rol-SysA) ) 

(functional-dependents  (Left-Elevon)  ) 

( f unctiona 1 ly-dependent-on  (Hydraulic-Line 

A)  )  ) 

( Ri ght-Elevon-Actua to r- 1  cont rol-sur f ace-actuator  (part-of  ( Fl ight-Cont rol-SysA ) ) 

( funct lona 1 -dependent s  (Right-Elevon)  ) 

( funct lonal ly-dependent-on  ( Hydr aul lc-Lin 

•A)  )  > 

( Lef t-Elevon-Actuator-2  cont rol -surf ace-actuator  (part-of  ( F 1 ight-Cont ro 1 -SysA ) ) 

( functional-dependents  ( Left-Elevon  !  > 

( funct l ona 1 ly-dependent-on  ( Hydr au 1 i c-Line 

B  )  M 

< Right-Elevon-Actuator-2  control-surface-actuator  'part-of  ( F 1 ight-Cont rol-SysA ) ’ 
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(functional-dependents  < Right-Elevon  )  ) 

( funct ional ly-dependent-on  (Hydraulic- Lin 


•  B  )  )  ) 


( Body-Flap-Actua tor-1  control-surface-actuator  (part-of  ( Flight-Contr  a1 -SysA)  ) 

( functional-dependents  (Body-Flap) ) 

<  funct ional ly-depen dent -on  ( Hydraul ic-LineA ) 

>  ) 

(Body-Flap-Actuator-2  control-surface-actuator  (part-of  { Flight-Cont rol-SysA) ) 

(functional-dependents  (Body-Flap) ) 

<  funct ional ly-dependent -on  ( Hydraul ic- Line B ) 

)  ) 

(Rudder-Actuator-1  control-surface-actuator  (part-of  ( FI ight-Cont rol-SysA ) ) 

(functional-dependents  (Rudder)) 

< funct ional ly-dependent-on  ( Hydraul ic-LineA) ) ) 

(Rudder-Actuator-2  control-surface-actuator  (part-of  ( Fl ight-Cont rol-SysA ) > 

(functional-dependents  (Rudder)) 

( functionally-dependent-on  ( Hydraul ic-LineB ) ) ) 

( Left-Elevon-Position  control-surface-position  (part-of  ( Flight-Control-SysA) > 

(associated-component  ( Lef t-Elevon ) > 
(association-type  ( ( Lef t-Elevon  parameter))) 
(functional-dependents  (Drag 

Attitude 
Lift  )  ) 

(causes  (((move-left  control-stick  )( increase 

Left-Elevon-Position) ) 

((move- right  control-stickM  decreas 

e  Left-Elevon-Position))))) 

( Right-Elevon-Posi tion  control-surface-position  (part-of  ( Fl ight-Cont rol-SysA ) ) 

(associated-component  ( Right-Elevon  )  ) 
(association-type  ((Right-Elevon  parameter) 


)  ) 

se  Right-Elevon-Posit ion ) ) 
e  Right-Elevon-Posit ion )) I ) ) 


(functional-dependents  (Drag 

Attitude 
Lift  )  ) 

(causes  (((move-right  cont rol-st ick ) ( increa 
( (move-left  control-stick) ( decreas 


( Body-F lap-Pos it  ion  control-surface-position  (part-of  ( Fl ight-Cont rol-SysA ) ) 

(associated-component  (Body-Flap) ) 
(association-type  {(Body-Flap  parameter))) 
(functional-dependents  (Drag 

At t 1 tude 
Lift  )  ) 

(causes  (((move-aft  cont rol-st ick )( increase  Bo 

dy-Flap-Pos it  ion ) ) 

( ( move-forward  control-stick) (decreas 

e  Body-Flap-Position))))) 

(Rudder-Position  control-surface-position  (part-of  ( Fl ight-Cont rol -Sys A ) ) 

(associated-component  (Rudder)) 

(association-type  ( (Rudder  parameter))) 
(functional-dependents  (Drag 

Attitude ) ) 

(causes  (((push  Lef t-Rudde r-Peda 1 )( decrease  Rudde 

r-Pos it  ion ) ) 

((push  Right-Rudder-Peda 1 )( increase  Rudd 

e  r-Pos i tion ) ) ) ) ) 


( Therma 1-Pro tect ion-SysA  aircraft-system  (part-of  (Climb-Plane 

Cruise-Plane 
Descent-Plane  )  > 
(parts  f Nosecap-Coo 1 ing 

Left-Wing-Cool ing 
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Right-Wing-Cooling 
Engino-Inlot-Cooling 
Eng inoA- Into  rna 1-Coo 1 ing 
EnginoB-  Into  rm  1  -Coo  ling 
Engino-Nozzlo-Coo  1  in', 

Vort-Tai 1-Cool ing 
Nosocap-Tomp 
Lof t-Wing-Tomp 
Right -Wing-Tomp 
Engino-inlot-Tomp 
EnginoA-Intorna 1-Tomp 
EnginoB-Intornal -Tomp 
Engmo-Nozz  lo-Tomp 
Vo rt -Tail -Tomp 
Fwd-Hyd-Coo ling- Pump 
Fwd-Eloc-Cool ing- Pump 
Lo  f  t -Hyd-Coo 1 ing- Pump 
Right-Hyd-Coo 1 ing- Pump 
Lof  t-Eloc-Cool ing- Pump 
Right-Eloc-Cool ing- Pump 
Fwd-Hyd-Coo 1 ing-Pr os su  ro 
Fwd-Eloc-Cool ing-Prossuro 
Lof t -Hyd-Coo 1 ing-Prossuro 
R lght -Hyd-Coo 1 ing-Prossuro 
Lo  ft -El oc-Cool ing-Prossuro 
Right-Eloc-Cooling-Prossuro ) ) 

( f unction a 1-dopondont s  ( Cl i mb- Plano 

Crui so-Plano 
Doscont -Plano ) ) 

( f unct lona 1 ly-dopondont-on  I Nosocap-Cool ing 

Lof t -Wing-Cool ing 
Right-Wing-Coo  ling 
Engino-Inlot-Cooling 
EnginoA-Intornal-Cool i 
ig 

EnginoB-Intornal -Cool i 
ig 

Engino- Nozzle-Cooling 
Vort-Tail-Cooling ) ) ) 

(  Nosocap-Cool ing  coo  1 ing-subsy s t om  (pact-of  ( Tho r ma 1 - P r ot oc t lon-Sy s A )  ) 

( associat od-sonsor s  l Nosocap-Tomp ) ) 

( f unct l on a 1-dopondont  s  (Thormal-Protoction-SysA 

Nosocap-Tomp ) ) 

( f unct ion a  1 ly-dopondont-on  <  Fwd-Hyd-Coo 1 inq-Pump 

Fwd-E loc-Coo 1 l ng-Pump )  ) ) 

(  Lof t-Wing-Cool ing  coo  1 ing-subsys tom  (part-of  ! Thermal-Protect lon-SysA H 

( associatod-sonsors  ‘ Lof t-Wing-Tomp ) I 
< f unct l ona 1 -dopondont s  ( Thormal-Protoct lon-SysA 

Lof t-Wing-Tomp ) ) 

( functional ly-dopondont-on  ( Fwd-Hyd-Coo 1 ing -Pump 

Fwd-Eloc-Cool ing-Pump ) ) I 

(Right-Wing-Cooling  cool ing-subsys tom  (part-of  ( Tho rma 1 - Pr o t oc t lon-Sy sA M 

(associatod-sonsors  ( Right -Wing-Tomp ) ) 

( functional- do pon do nts  (Thormal-Protoction-SysA 

Right -Wing-Tomp i I 

(  functional ly-dopondont-on  ( Fwd-Hyd-Coo 1 i ng-Pump 

Fwd-E 1 oc-Coo 1 ing-Pump i ) ) 


(Engino-Inlot-Cooling  cool ing-subsys tom  (part-of  < Thermal -Protect lon-SysA i * 

f associatod-sonsor s  < Eng  mo- 1 nl ot -Tomp >  » 

( f unct ion a  1 -dopondont  s  (Thormal-Protoction-SysA 

Eng inoA 
EnginoB 

Engino- Inlot -Tomp l » 

f  functional ly-dopondont-on  ' Loft -Hyd- Cool ing-Pump 

Right- Hyd-Cooling- Pump 
Loft-Eloc-Cooling-Pump 
Riaht -El oc-Coo lina-Fump 


(  EngmeA-lnternal-Cooling  cooling-subsystem  (part-of  (Thermal-Protection-SysA)) 

(associated-sensors  ( EngineA-Interna 1-Temp ) ) 

( f unct ional-dependent s  ( Thermal-Protect ion-SysA 

EneineA 

EuiineA-Internal-Temp ) I 
( funct ional ly-dependent-on  ( Lef t-Hyd-Cool ing-Pu 
mp 

Left-Elec  Cooling-P 

ump ) ) ) 

(  EngmeB-Internal-Cool  ing  cooling-subsystem  (part-of  (  Therma  1-Protect  ion-SysA  )  ) 

(associated-sensors  ( EngineB-Inte rna 1 -Temp ) I 
( functional-dependents  (Thermal-Protection-SysA 

Enginefl 

EngineB-Inte rna 1-Temp  I ) 

( funct ional ly-dependent-on  ( Ri ght-Hyd- Cool ing- P 

ump 

Right-Elec-Cool i 

ng-Pump  > ) ) 

(  Engine-Noszle-Cool ing  cooling-subsystem  (part-of  (  Thermal-Protect ion-SysAM 

(associated-sensors  ( Engine-Nozzle-Temp ) ) 

( functional-dependents  ( Thermal-Protect ion-SysA 

EngineA 

EngineB 

Engine-Nozzle-Cooling) ) 

( funct ion a  1 ly-dependent-on  { Lef t-Hyd-Cool ing- Pump 

Righ t-Hyd-Cool ing- Pump 
Lef t -Elec-Cool ing- Pump 
Right -Elec-Cool ing-Pum 

p  )  )  ) 

( Vert-Tail-Cooling  cooling-subsystem  (part-of  ( Thermal-Protection-SysA) ) 

(associated-sensors  (Vert-Tail-Temp) ) 

( f unct iona 1 -dependents  (Thermal-Protection-SysA 

Vert-Tail-Temp) ) 

( functional ly-dependent-on  ( Lef t-Hyd-Cool ing- Pump 

Righ t-Hyd-Cool ing- Pump 
Lef t -Elec-Cool ing- Pump 
Right-Elec-Coo  1 ing-Pump )  )  ) 

< Fwd-Hyd-Cool ing-Pump  cooling-pump  (part-of  ( The rma 1-Pr o t ect lon-Sy s A ) ) 

(associated-sensors  ( Fwd-Hyd-Cool ing-Pressure  )  ) 

( f unct ion a  1 -dependents  (Nosecap-Cooling 

Lef t -Wing -Cool ing 
Right -Wing-Coo  ling 
Pwd-Hyd-Cool ing-Pres su re > ) 

( funct ional ly-dependent-on  (Hydraulic-LineB 

rue  1 -LineA ) ) > 

( Fwd-E 1 ec-Coo 1 ing-Pump  cooling-pump  (part-of  (Thermal-Protect ion-SysA ) 1 

(associated-sensors  i Fvd-Elec-Coo I ing-Pressure >  ) 

<  functional- dependents  (Nosecap-Cooling 

Left-Wing-Cooling 
Right -Wing -Cool ing 
Fwd-Elec-Coo 1 ing-Pressure »  > 
'functional ly-dependent-on  <  Elect  r lc-Gener a  tor A 

Fuel -LineB ) »  ' 


!Left-Hyd-Cool ing-Pump  cool ing-pump 


'part-of  < Therma 1-Protect ion-SysA i ) 
'associated-sensors  ( Le f t -Hyd-Coo 1 ing- Pres s u r e i i 
'  funct ional -dependents  f Engine- Inlet-Cool ing 

EngineA-Interna 1-Cooling 
EngineB-Interna 1-Coo  ling 
Engine- Nozzle-Cooling 
Vert-Tail-Cooling 
Lef t -Hyd-Coo 1 ing-Pres su r e i 
(  funct ional ly-dependent-on  'Hydraulic-LineB 

Fuel -LineB  *  »  ' 


i Lef t-E lec-Coo 1 ing-Pump  cooling-pump  'part-of  ( The rma 1 -Protect ion-SysA i * 

'assoc  late d- sensors  < Left-Elec-Cool ing-Pressure  1 
'function a’- dependents  'Engine-Inlet-Coolina 


EngineA- Internal -Cooling 

EngineB-Inte  rna 1 -Cool ing 

Engine-Nozzle-Cooling 

Vert-Tai 1-Cooling 

Lef  t-Ele —  Cooling-Pressure  )  ) 

( f unct lona 1 ly-dapandant-on  ( Elect r ic-Generato r A 

Fuel-LineA ) ) ) 

(  R 1 ght-Hyd-Coo 1 mg-Pump  cooling-pump  (part-of  < Tha rma 1 -Protect lon-SysA )  ) 

(associated-sensors  ( Right-Hyd-Cool ing-Pressure ) > 

( functional -dependants  (Engina-Inlat-Cooling 

Engine A- Internal -Coo 1 ing 
EngineB-Inte rna 1-Coo 1 ing 
Engine-Nozzle-Cooling 
Vert-Tail -Cool ing 
Right-Hyd-Cool ing-Pressure ) ) 

( functional ly-de pendent -on  ( Hydraul lc-LineA 

Fuel-LineA) ) ) 

(  Right-Elec-Cool ing-Pump  cooling-pump  (part-of  < Thermal-Protection-SysA)  ) 

{  associated-sensors  (  Right-Elec-Cool  ing-Pres*7  ”«  )  ) 

{ functional-dependents  ( Engine-Inlet-Cool inc 

EngineA-Int e rna 1 -Cool ing 
EngineB-Inte rna 1-Cool ing 
Engine-Nozzle-Cooling 
Vet  t-Ta ll-Cooling 
Right-Elec-Coo  1 ing-Pressure )  ) 

( funetionally-dependent-on  ( Elect r ic-Gene rat or B 

Fuel-LineB ) ) ) 

(  Nosecap-Temp  temp-sensor  (part-of  ( The rma 1-Protect lon-SysA )  ) 

(associated-component  ( Nosecap-Cool ing ) ) 

(association-type  (( Nosecap-Cool ing  parameter))) 

(causes  (((increase  A1 ti tudeA >( decrease  Nosecap-Temp)) 

((decrease  AltitudeA) ( increase  Nosecap-Temp)) 

((increase  Ai r speedA > ( inc rease  Nosecap-Temp)) 

((decrease  Ai rspeedA )( decrease  Nosecap-Temp)) 

((increase  MachA )( increase  Nosecap-Temp)) 

((decrease  MachA I ( decrease  Nosecap-Temp)) 

((increase  Fwd-Hyd-Cool ing-Pressure )( decrease  Nosecap-Te 

mp  )  ) 

((decrease  Fwd-Hyd-Cool ing-Pressure H increase  Nosecap-Te 

mp )  ) 

((increase  Fwd-E 1 ec-Coo 1 i ng- P r es s u r e  )  ( dec i ea s e  Nosecap-T 

emp  )  ) 

((decrease  Fwd-Elec-Cool ing-Pressure U increase  Nosecap-T 

emp  <  )  )  '  ) 


'Left -Wi ng- 


g-Temp ) ) 


g-Temp  ) 


ng-Temp  »  ) 
ng-Temp ) > ) ' 


Temp  temp-sensor  (part-of  ( Thermal-Protection-SysA ) ) 

( associated-component  ( Left -Wing-Cool ing )  > 

(association-type  ((Left-Wing-Cooling  parameter!'' 

(causes  ('(increase  Al 1 1 tudeA )( dec rea se  Lef t -Wi ng-Temp  '  1 
'(decrease  AltitudeA) ( increase  Left-Wing-Temp)' 
((increase  AirspeedA) ( increase  Lef t -Wi ng-Temp *  > 
'(decrease  AirspeedAM  decrease  Le  f  t -Wi  ng-Temp  )  ' 
((increase  MachAi ( increase  Le f t -Wt ng-Temp )  * 

'(decrease  MachA' 'decrease  Left-Wing-Temp'’ 

((increase  Fwd-Hyd-Coo 1 l ng-Pr es su r e » < dec r ea se  Left-Win 

''decrease  Fwd-Hyd-Cool  lnq-Pressure  1  '  increase  Left-Wm 

''increase  Fwd-E 1 ec -Coo  1 1 ng- Pres su r e )< dec i eas e  Left-Wi 

'•decrease  Fwd-Elec-Coolinq-Pressure 1  1  increase  Left-Wi 


'Right-Wing-Temp  temp-sensor  (part-of  < The r ma 1 -P t o t ec t l on- Sy sA ' • 

'associated-component  ( P l ght -Wi ng-Coo 1 i ng >  ' 

( a s s oc i a 1 1  on  -  type  1  (Right-Wing-Cooling  parameter  ' 

'causes  (''increase  Al t l tudeA »' dec r ea s e  Pioht  Wing-Temp1 
• 'decrease  AltitudeA' ! increase  Right-Wing-Temp1 
''increase  Ai r^peedAi  1  increase  P i qht -Wi ng-Temp 1 
''decrease  Ai rspeedA )' decrease  P i oht -Wi no-Temp ' 


((increase  MachA M increase  Right-Wing-Temp ) ) 

((decrease  MachA )( decrease  Right-Wing-Terap ) ) 
((incraasa  rwd-Hyd-Cool ing-Pras su re )( dacraasa  Right-W 


..VAVy^P  hXa'FJ*  w>  V  V  /  S'  A  rf". 


c 


A 

a 


ing-Temp ) ) 
i ng-Tamp ) ) 
Wing-Tamp  )  > 
Wing-Temp )  )  )  1  ) 


( (dacraasa  Fwd-Hyd-Coo 1 ing-Pras ra )( inc rease  Right-W 
((incraasa  Fwd-Elac-Cool ing-Pressuta ) { dac raasa  Right- 
( (dacraasa  Fwd-Elac-Cool ing-Pressure )( inc raasa  Right- 


( Engina-Inlat-Tamp  temp-sensor 


ne-Inlet-Temp ) ) 
ne-Inlet-Temp  )  ) 
ine-Inlet-Temp )  ) 
ina-Inlat-Tamp > ) 
ine-Inlet-Temp )  ) 
me- Inlet-Temp  >  ) 
gine-Inlet-Tamp )  ) 
gine-Inlet-Tamp) ) ) ) * 


(part-of  ( Therma 1-Protact ion-SysA ) ) 

(associated-component  ( Engine- Inlat-Cool ing ) ) 

( associa t ion-typa  ( ( Engine-Inlat-Cool ing  parameter )  )  ) 

(causes  (((incraasa  Al t i tudaA )( dac raasa  Engina-Inlat-Tamp) } 
({dacraasa  Alt i tudaA )( increase  Engina- Inlat-Tamp M 
((incraasa  Ai rspaadA )( incraasa  Engina-Inlat-Tamp ) ) 
{(dacraasa  Ai rspaadA )( dac raasa  Engina-Inl at-Tamp ) ) 
({incraasa  MachA )( inc raasa  Engina-Inlat-Tamp ) ) 
((dacraasa  MachA M dac raasa  Engine-Inle t-Temp M 
((incraasa  Laf t-Hyd-Cool ing-Prassura )( dacraasa  Engi 


( ( dacraasa 
(  ( incraasa 
( ( dacraasa 
( ( incraasa 
( ( dacraasa 
( ( incraasa 


Laf t-Hyd-Cooling-Prassura ) ( incraasa  Engi 
Laft-Elac-Cooling-Prassura) (dacraasa  Eng 
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Appendix  C'.  Users'  Manual  for  the  A  ASP  System  Status  Monitor 


C.l  File  Structure 

The  N'ASP  System  Status  Monitor  (SSM)  is  divided  into  separate  program  and  data  files 
distributed  among  seven  subdirectories  in  the  Symbolics  3600  file  system.  Each  of  the  subdirectories 
has  the  prefix  "host:>icat>alpha-demo,"  where  "host"  is  the  host  name  of  the  particular  Symbolics 
computer  on  which  the  SSM  is  running.  The  seven  subdirectories  are: 


1.  packages 

2.  blackboard 
3  interface 

1  monitor 

■V  datafiles 

0  Stage  1 

7  stage2 


Each  of  the  seven  subdirectories  contains  several  files  with  pathnames  of  the  form  "host:>icat>alpha- 
demo>blackboard>x.y.z. '  where  “x"  is  the  filename,  "y“  is  the  file  extension,  and  *‘z”  is  the  file's 
version  number 

There  is  one  file  us<  d  by  the  SSM  which  is  not  contained  in  one  of  the  seven  subdirectories. 
This  file  is  "host:>icat>alpha-demo>alpha-demo-loader.lisp."  and  is  used  on  start-up  to  load  all  the 
other  program  files  from  the  seven  subdirectories  into  the  computer's  memory. 


i'J  Installation 

If  t  he  NASP  SSM  is  to  be  installed  on  a  different  Symbolics  computer,  all  of  t  lie  SSM  program 
wid  lata  files  must  reside  m  the  same  subdirectories  as  listed  in  the  preceding  section  Ibis  i'¬ 


ll  2 


■,'t*1  \P."-V  r  r^rr^T  '-•;  v.vjy  j  *■ . y:y.  7 '._“  .;»X7\7\7  \w  v  ■,'  •_•  ■_- 


K: 

i 


s 


required  because  the  various  files  are  specified  by  their  full  pathnames  when  they  are  loaded  into 
memory. 

C.3  Operation 

The  following  steps  should  be  taken  to  operate  the  NASP  System  Status  Monitor. 

C.3.1  Loading  After  booting  the  Symbolics  computer,  the  following  command  should  be 
typed  at  any  Lisp  Listener  prompt; 

(load  ">icat>alpha-demo>alpha-demo- loader" ) 

After  typing  the  closing  parenthesis,  the  command  will  be  executed,  and  the  SSM  files  will  be 
loaded  into  the  computer’s  memory.  After  all  of  the  SSM  files  have  been  loaded,  the  Lisp  Listener 
prompt  will  reappear. 

C.3. 2  Start-up  After  the  SSM  files  have  been  loaded,  the  following  command  should  be 
typed  at  the  Lisp  Listener  prompt; 

(blk:interact  t) 

This  command  will  start  the  SSM  in  the  interactive  mode.  The  start-up  process  will  take  up 
to  five  minutes.  When  the  start-up  is  complete,  the  NASP  SSM  System  Display  (Figure  9)  will 
appear,  with  a  mouse-sensitive  menu  in  the  lower  righthand  corner  of  the  display. 

C.3. 3  Using  the  SSM  The  user  interacts  with  the  SSM  by  entering  fault  symptoms,  starting 
the  diagnosis  and  remediation  functions,  and  then  reviewing  the  results. 


C.3. 3.1  Entering  Fault  Symptoms  To  enter  fault  symptoms  into  the  SSM,  the  user 
should  use  the  mouse  to  choose  the  "Set  Symptoms"  selection  in  the  “Interactive  Monitor  Menu.' 
The  next  menu  is  the  "Set  Symptoms  Menu."  where  the  user  should  select  “Add  a  Symptom."  The 
next  menu  is  the  "Select  Systems  Menu"  from  which  the  user  should  select  the  aircraft  system  or 
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subsystem  where  the  fault  symptom  is  to  appear.  After  selecting  an  aircraft  system,  that  system's 
sensor  menu  will  appear,  and  the  user  should  select  one  of  the  sensors.  Finally,  the  "Sensor  Value 
Menu"  will  appear,  and  the  user  should  select  the  desired  value  to  apply  to  the  selected  sensor. 
After  selecting  a  sensor  value,  the  user  will  be  returned  to  the  "Set  Symptoms  Menu  "  From  here, 
the  user  can  either  repeat  the  process  listed  above  to  enter  more  fault  symptoms,  or  select  "Quit" 
to  return  to  the  "Interactive  Monitor  Menu.” 

C.S.  j.J  Starting  the  Diagnosis  and  Remediation  Functions  After  symptoms  have  been 
set  and  the  user  has  returned  to  the  “Interactive  Monitor  Menu,”  the  diagnosis  and  remediation 
functions  are  started  by  simply  choosing  the  “Exit  Monitor"  selection  When  these  functions  have 
completed,  the  current  symptoms  will  be  displayed  in  the  Monitor  Pane,  and  the  results  of  the 
diagnosis  function  will  be  displayed  in  the  Diagnosis  Pane.  If  the  diagnosis  results  cannot  all  fit  in 
the  Diagnosis  Pane  at  one  time,  the  word  “*more*”  will  appear  at  the  bottom  of  that  pane.  The  user 
should  press  any  key  on  the  computer  keyboard  to  display  the  next  page  of  diagnosis  information. 
This  process  is  repeated  until  the  last  page  of  diagnosis  information  has  been  displayed  and  the 
"AirplaneA  Menu"  appears. 

From  the  "AirplaneA  Menu,”  the  user  can  enter  more  or  additional  symptoms  by  selecting 
"Update,”  review  the  diagnosis  or  remediation  results  by  selecting  “Review  Diagnosis,”  review  one 
of  the  other  aircraft  system  displays  by  selecting  its  name,  or  stop  the  SSM  by  selecting  "Stop.” 
If  the  user  selects  "Update"  at  this  point  and  then  adds  more  symptoms,  the  new  symptoms  will 
be  added  to  the  old  symptoms.  The  diagnosis  function  will  consider  all  the  symptoms  together, 
although  it  will  only  display  the  most  recently  added  symptoms  in  the  Monitor  Pane.  If  the  user 
selects  “Initialize”  before  adding  new  fault  symptoms,  the  previous  symptoms  will  be  deleted  and 
only  the  most  recently  added  symptoms  will  be  considered  by  the  diagnosis  function. 
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The  purposes  of  this  study  were  to  develop  a  model  for  an  in-fligh1 
diagnostic  system  that  could  be  applied  to  the  National  Aerospace  Plane 
and  to  implement  a  computer  program  to  demons  t  rate  the  feasibility  of  1 1 
model  as  a  basis  for  a  svstem  status  non'tor. 

The  diagnostic  system  model  which  was  developed  features  a  double 
hierarchy  structure,  one  for  the  aircraft  functions  to  be  diagnosed,  an 
another  for  the  diagnostic  functions  to  be  performed.  The  hierarchical 
nature  of  both  the  svstem  knowledge  and  the  functions  that  use  the  know 
ledge  allow  decomposition  of  the  diagnostic  task  into  relatively  indepe 
ent  and  manageable  parts. 

The  demonstration  program  which  was  develooed  includes  a  subset  of 
the  diagnostic  svstem  model.  This  program  was  implemented  in  Zetalisp 
on  a  Svmbolics  3600  computer.  It  will  simulate  monitoring  the  dvnamic 
performance  parameters  of  an  aircraft's  subsystems,  report  any  readings 
that  fall  outside  of  predetermined  limits,  reason  about  components 
responsible  for  the  fault,  display  to  the  aircrew  the  other  aircraft 
functions  which  may  be  affected  by  the  component  failure,  and  recommend 
actions  that  mav  remedy  the  fault  situation. 

The  demonstration  program  clearly  shows  the  validitv  of  the  diagno 
svstem  model  and  highlights  the  importance  of  the  causal  and  functional 
relationship  techniaues  used  to  represent  knowledge  of  the  aircraft  and 
its  environment.  The  program  demonstrates  how  the  diagnostic  svstem  ca 
supply  relevant  svstem  status  informat. on  to  the  aircrew.  The  report 
concludes  with  several  recommendations  for  enhancements  to  the  demonstr 


